On Dec 8, 12:42 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> MonkeeSage a écrit :
>
> > On Dec 7, 11:08 pm, Steve Howell <[EMAIL PROTECTED]> wrote:
>
> (snip)
> >> 4) Ruby forces you to explicitly make attributes for
> >> instance variables. At first I found this clumsy, but
> >> I've gotten used to it, and I actually kind of like it
> >> in certain circumstances.
> > 4.) Yeah, it's hard when learning ruby, especially if coming from
> > languages that distinguish between methods and attributes,
>
> which is not the case in Python
It is, I just wasn't absolutely precise (uh-oh, here comes the
semantics police! -- don't pass GO, don't collect $200, go strait to
jail!). Python *does* distinguish between instance/class vars and
instance/class methods. But in ruby no such distinction exists.
Accessing a "variable" in ruby == calling object.var. I.e., in ruby,
when you say "blah.x" that translates to "blah.send(:x)", whether :x
is a "variable" or a "method," since *everything* is a method. The
call model of ruby is more like smalltalk.
> > to get used
> > to thinking of "a.a" and "a.a=" as method calls and defining accessors
> > for those methods (or using one of the attr_* keywords) in the class
> > body.
>
> Python has an equivalent support for computed attributes, using property
> or a custom descriptors. While it's a bit lower-level than Ruby, it's
> still quite easy to use and IMHO a bit more powerful.
>
> > The equivalent python idiom is something like:
>
> > class A:
> > __a = "foo"
> > def __init__(self):
> > self.a = A.__a
>
> WTF ???
>
> > Which roughly translates to this in ruby:
>
> > class A
> > attr_accessor :a
> > def initialize
> > @a = "foo"
> > end
> > end
>
> The Python translation of the above Ruby snippet is actually way more
> simple:
>
> class A(object):
> def __init__(self):
> self.a = "foo"
>
> > Python:
Not really. In ruby an ivar is accessible within the class *only*, but
not from without (like a mangled python class var), unless you declare
an accessor (or write the accessor methods yourself). So my example is
closer, and is not a WTF, if you know how ruby works.
> > 1.) I also found python's style of method referencing to be a lot more
> > intuitive than using something like ruby's "m = method('foo');
> > m.call('bar')" to get a reference to foo() and call it. It's alot
> > cleaner to say "m = foo; m('bar')", imo. But this goes back to the
> > omitting parens thing, which makes it impossible to do it that way in
> > ruby.
>
> Yeps. This is where the real and fundamental difference between Ruby and
> Python becomes evident. Both have support for transparent computed
> attributes, but the way it's implemented is totally different - in Ruby,
> by not having a call operator at all (I mean, the parens), in Python by
> having both an explicit call operator and an explicit protocol for
> computed attributes (the descriptor protocol). Not to say one is better
> than the other, but that while both languages have similar features
> (and, at first look, similar syntaxes), they really have totally
> different object models.
Yes and no. I'll leave it at that. If you want to know more, do your
homework. :P
> > Though, ruby does allow some interesting things by having it
> > that way, e.g., letting you substitute a Proc object (e.g., a block or
> > lambda) for a method reference transparently.
>
> Care to give an example ? I don't have enough working experience with
> Ruby to be sure I understand what you mean here.
For example, any place expecting a foo (method reference), can be
exchanged with a { "bar" } block or a lambda { "baz" }.
> > 2.) I also find layout to be a nice feature. And since I've recently
> > been using Haskell, it has only re-inforced that opinion. But when I
> > first started using python, I got bitten by IndentationError quite
> > often. And I kept wanting to type some closing symbol, heh. ;)
>
> The nice thing with Python is that it lets you use the closing symbol
> you want, as long as you prefix it with a '#' !-)
LOL. Well, yes, I used to do that, but I got over that irrational
urge. ;)
Regards,
Jordan
--
http://mail.python.org/mailman/listinfo/python-list
