[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[curiousity] why aren't declarations just syntactic sugar?

Lionel Thiry

4/5/2005 11:26:00 PM

Hello!

I'd like to know why in ruby, a construction like:
class MyClass
...
end

isn't just a syntactic sugar for:
MyClass = Class.new do
...
end

Is it a problem about block variable binding? Is it a problem of speed?
Something else?

Thanks in advance.

--
Lionel Thiry
13 Answers

Hal E. Fulton

4/5/2005 11:31:00 PM

0

Lionel Thiry wrote:
> Hello!
>
> I'd like to know why in ruby, a construction like:
> class MyClass
> ...
> end
>
> isn't just a syntactic sugar for:
> MyClass = Class.new do
> ...
> end
>
> Is it a problem about block variable binding? Is it a problem of speed?
> Something else?

I've seen this discussed... I think it's just historical reasons
first of all. I'm not sure this kind of unification was "thought of"
at the beginning.

But there are also other considerations, I think. For example, a block
is a closure, whereas the body of a class definition is not. A question
of scope.


Hal

Bill Kelly

4/5/2005 11:32:00 PM

0

From: "Lionel Thiry" <lthiryidontwantspam@skynetnospam.be>
>
> I'd like to know why in ruby, a construction like:
> class MyClass
> ...
> end
>
> isn't just a syntactic sugar for:
> MyClass = Class.new do
> ...
> end

It'd probably at least have to be:

(MyClass ||= Class.new) do

so we can re-open classes as we currently do.

Other than that... I dunno... :)


Regards,

Bill

nobu.nokada

4/5/2005 11:33:00 PM

0

Hi,

At Wed, 6 Apr 2005 08:24:39 +0900,
Lionel Thiry wrote in [ruby-talk:137002]:
> class MyClass
> ...
> end

class hides outer scope, so this causes an error.

x = 1
class MyClass
p x # => Name Error
end

> isn't just a syntactic sugar for:
> MyClass = Class.new do
> ...
> end

But block doesn't.

--
Nobu Nakada

ES

4/6/2005 2:09:00 AM

0

Lionel Thiry wrote:
> Hello!
>
> I'd like to know why in ruby, a construction like:
> class MyClass
> ...
> end
>
> isn't just a syntactic sugar for:
> MyClass = Class.new do
> ...
> end
>
> Is it a problem about block variable binding? Is it a problem of speed?
> Something else?
>
> Thanks in advance.

I, I think that is a good idea. On the other hand, I also think that

def foo(x)
do_something_with x
end

Should be syntactic sugar for

def(:name => :foo,
:bind => binding,
:body => {|x| do_something_with x}
)

Then again, the current system works well too :)

> Lionel Thiry

E

Dave Burt

4/6/2005 2:46:00 AM

0

"Bill Kelly" <billk@cts.com> scribbled:
> It'd probably at least have to be:
>
> (MyClass ||= Class.new) do
>
> so we can re-open classes as we currently do.

"MyClass do ..." looks like a syntax error to me.

How about a Class#| for this (think set union like Array#|)?

MyClass |= Class.new do
....

First-class methods would make implementation of something like this
convenient.

Cheers,
Dave


Florian Groß

4/6/2005 12:51:00 PM

0

Dave Burt wrote:

> "MyClass do ..." looks like a syntax error to me.
>
> How about a Class#| for this (think set union like Array#|)?
>
> MyClass |= Class.new do
> ....
>
> First-class methods would make implementation of something like this
> convenient.

That would not work though as the block can not bind to the | operator.

Dave Burt

4/7/2005 6:29:00 AM

0

"Florian Groß" <florgro@gmail.com> responded:
> Dave Burt wrote:
>
>> "MyClass do ..." looks like a syntax error to me.
>>
>> How about a Class#| for this (think set union like Array#|)?
>>
>> MyClass |= Class.new do
>> ....
>>
>> First-class methods would make implementation of something like this
>> convenient.
>
> That would not work though as the block can not bind to the | operator.

I know that. I was thinking, "what if you could add all the methods defined
in that anonymous class to MyClass?"

This would effectively be a way of doing multiple inheritance, and has all
the problems associated with that. (e.g. Class.new will make a class that
inherits from Object, and those methods would have to be "ORed" into MyClass
as well as any explicitly defined.) So it's a bad thing.

It makes more sense if the RHS is a Module. And you can do that already,
with mix-ins (extend, include)

I still think it's an interesting thought.

Cheers,
Dave


Curt Sampson

4/8/2005 4:50:00 AM

0

Jon Raphaelson

4/8/2005 5:25:00 AM

0

Curt Sampson wrote:
<snip>
>
> For example: explain the results of these two programs to me:
>
> ----------
> def do_me_harder
> puts "Oh yes!"
> end
>
> puts do_me_harder
> ----------
> module Foo
>
> def do_me_harder
> puts "Oh yes!"
> end
>
> puts do_me_harder
> end
> ----------
>
> cjs

Both of those will produce the output

Oh yes!
nil

which is absolutly correct. I'm not sure what the problem with those is.
If it is that you are confused about the nil, that's because puts
returns nil, and you are puts'ing the result of do_me_harder, which is
the result of the last expression in do_me_harder, which is a puts and
hence nil.

If the confusion is that the program wrapped in a module prints
something, that is because, unlike other programming languages where the
class/module defintions are read but not executed, in ruby those
definitions are executed. This is really useful, for example this is the
way alias works and mixins I believe (but I don't know for sure, so if
I'm worng sorry), as well as most domain specific language stuff.

Dominik Bathon

4/9/2005 5:46:00 PM

0

On Fri, 08 Apr 2005 07:24:54 +0200, Jon Raphaelson
<jonraphaelson@gmail.com> wrote:

> Curt Sampson wrote:
> <snip>
>> For example: explain the results of these two programs to me:
>> ----------
>> def do_me_harder
>> puts "Oh yes!"
>> end
>> puts do_me_harder
>> ----------
>> module Foo
>> def do_me_harder
>> puts "Oh yes!"
>> end
>> puts do_me_harder
>> end
>> ----------
>> cjs
>
> Both of those will produce the output
>
> Oh yes!
> nil

No, they won't ;-)

The 2nd will raise an exception:
NameError: undefined local variable or method `do_me_harder' for Foo:Module

do_me_harder is an instance method (you can only call it on an instance of
a class including Foo):

class A
include Foo
end

A.new.do_me_harder

But the following would work:

module Foo
def Foo.do_me_harder
puts "Oh yes!"
end

puts do_me_harder
end

In this case do_me_harder is a singleton method of module Foo.

HTH,
Dominik