[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

"module model", how to call it properly?

Csaba Henk

2/24/2005 12:11:00 AM

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
7 Answers

Robert Klemme

2/24/2005 9:24:00 AM

0


"Csaba Henk" <csaba@phony_for_avoiding_spam.org> schrieb im Newsbeitrag
news:slrnd1q6sp.c22.csaba@ms0.math.ucalgary.ca...
> 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

2/24/2005 9:57:00 AM

0

On 2005-02-24, Robert Klemme <bob.news@gmx.net> wrote:
> "Csaba Henk" <csaba@phony_for_avoiding_spam.org> schrieb im Newsbeitrag
>> 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....

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

2/24/2005 10:13:00 AM

0


"Csaba Henk" <csaba@phony_for_avoiding_spam.org> schrieb im Newsbeitrag
news:slrnd1r96t.c22.csaba@ms0.math.ucalgary.ca...
> On 2005-02-24, Robert Klemme <bob.news@gmx.net> wrote:
> > "Csaba Henk" <csaba@phony_for_avoiding_spam.org> schrieb im
Newsbeitrag
> >> 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....
>
> 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

2/24/2005 1:24:00 PM

0

On 2005-02-24, Robert Klemme <bob.news@gmx.net> wrote:
> 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

2/24/2005 2:42:00 PM

0


"Csaba Henk" <csaba@phony_for_avoiding_spam.org> schrieb im Newsbeitrag
news:slrnd1rlbv.c22.csaba@ms0.math.ucalgary.ca...
> On 2005-02-24, Robert Klemme <bob.news@gmx.net> wrote:
> > 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? :)

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

ruby talk

2/24/2005 2:59:00 PM

0

On Thu, 24 Feb 2005 23:45:03 +0900, Robert Klemme <bob.news@gmx.net> wrote:
> ...
> 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


google

2/24/2005 10:57:00 PM

0

> > > 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.
> >
> > 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.

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/...
http://www.erikveen.dds.nl/distributingrubyapplications/...

gegroet,
Erik V.