"module model", how to call it properly?

[Csaba Henk]

Hi!

Well, I just don't know the proper expression...

I can speak of things like comparing Ruby's and Python's object model.

However, how to speak of a comparison of Ruby's and Python's "module
model", that is, the way the language treats modular code, the way and
the semantics of accessing code in external files... ?

As in Ruby the word "module" is used for something else, the above
terminology leads to nowhere but confusion.

I'd like to find a better term. Optimally one which means the right
thing all across comp.lang.*. Any suggestions?

Csaba

 

[Robert Klemme]

Hi!

Well, I just don't know the proper expression...

I can speak of things like comparing Ruby's and Python's object model.

However, how to speak of a comparison of Ruby's and Python's "module
model", that is, the way the language treats modular code, the way and
the semantics of accessing code in external files... ?

As in Ruby the word "module" is used for something else, the above
terminology leads to nowhere but confusion.

I'd like to find a better term. Optimally one which means the right
thing all across comp.lang.*. Any suggestions?

Csaba

How about "component"? You can view every required file as a component
because it's a physical separate entity. OTOH typically libs consist of
different files - I guess you have to call a group of related files a
component then....

Kind regards

robert

 

[Csaba Henk]

How about "component"? You can view every required file as a component
because it's a physical separate entity. OTOH typically libs consist of
different files - I guess you have to call a group of related files a
component then....

Hm, this sounds good! Thanks! The things is not that I'd want to flood
all the comp.lang.* groups with comparisons between the component model
of Ruby and *, rather I seek words for thinking...

Thinking is so much inclined to language such that I can't think about
such things under the bathtube without having the proper words. Cf.
Matz's Oscon '03 slides.

Csaba

 

[Robert Klemme]

Hm, this sounds good! Thanks! The things is not that I'd want to flood
all the comp.lang.* groups with comparisons between the component model
of Ruby and *, rather I seek words for thinking...

Thinking is so much inclined to language such that I can't think about
such things under the bathtube without having the proper words. Cf.
Definitely!

Matz's Oscon '03 slides.

This stirred up another idea: what if we could distribute components as
zip files? require would then need to look at these, too. I don't
oversee all implications yet, but it might be worth thinking a bit more
about this as this could make deployment easier.

Cheers

robert

 

[Csaba Henk]

This stirred up another idea: what if we could distribute components as
zip files? require would then need to look at these, too. I don't
oversee all implications yet, but it might be worth thinking a bit more
about this as this could make deployment easier.

Hm, shall we steal the good bits of the yet untouched languages, like...
Java?

What real-life demands could be better satisfied by this? For the
Windows platform, there is rubyscript2exe, for the others, there are
rakefiles, gems,... I don't say these work perfectly, but they are on
the right path for making installing packages painless, aren't they?

And yet there are no such huge packages for which the compression gained
by zipping would be a major benefit. Or...?

Csaba

 

[Robert Klemme]

Hm, shall we steal the good bits of the yet untouched languages, like...
Java?

How did you know I was thinking of Java? )

What real-life demands could be better satisfied by this? For the
Windows platform, there is rubyscript2exe, for the others, there are
rakefiles, gems,... I don't say these work perfectly, but they are on
the right path for making installing packages painless, aren't they?

And yet there are no such huge packages for which the compression gained
by zipping would be a major benefit. Or...?

You're probably right. Gem is far more convenient than downloding a zip
and placing it somewhere and it does use compressed files during
transportation AFAIK. IMHO the major advantage would not be compression
but bundling of several files into a single physical entity. But, yes, I
guess gems do that better.

Kind regards

robert

 

[James G. Britt]

...
You're probably right. Gem is far more convenient than downloding a zip
and placing it somewhere and it does use compressed files during
transportation AFAIK. IMHO the major advantage would not be compression
but bundling of several files into a single physical entity. But, yes, I
guess gems do that better.

I like the idea of bundling resources a s a single entity in a way
that discourages (though does not prevent) user hacking.

Might this be useful for updating parts of an application , where you
don't want each part distributed as a distinct library (a la gems),
but more along the lines of a local Ruby .so or .dll? You could then
version segments of an application.

Would it be useful for localization? Compress multiple language files
into a zip, and have the code extract only what it needs?

James

 

[Erik Veenstra]

This stirred up another idea: what if we could distribute

You're probably right. Gem is far more convenient than
downloding a zip and placing it somewhere and it does use
compressed files during transportation AFAIK. IMHO the major
advantage would not be compression but bundling of several
files into a single physical entity. But, yes, I guess gems
do that better.

If you're interested in bundling several files into a single,
runnable file (and you are...), you might want to read the
following sites:

http://www.erikveen.dds.nl/tar2rubyscript/index.html
http://www.erikveen.dds.nl/distributingrubyapplications/index.html

gegroet,
Erik V.