From: Mathieu Bouchard <matju@...>
Date: 2001-12-19T01:45:32+09:00
Subject: [ruby-talk:28873] Perl features missing in Ruby


(just done with the final exams)

On Sun, 9 Dec 2001, Phil Tomson wrote:
> Coming to Ruby from Perl-land myself...  I didn't use tie very often in my 
> Perl programs (actually, only once or twice) but it does seem like a 
> useful feature.  I think, in general, you use a tie to intercept 
> assignments to, or reading from an object of a builtin type.

Libraries use it the most. I prefer to see them as abstract base
classes. That's what they really are in M�taRuby anyway.

> >2. In Ruby, there is _no_ equivalent to SCALAR. In Ruby, variables are not
> >objects; in Perl they are fcv ("first-class value")
> And this, presumably, is what is making it hard to emulate a tied scaler 
> in MetaRuby - correct?

Well, one'd have to start by defining a scalar interface for Ruby. For
example:

class Scalar
  def []; @value end
  def []=x; @value=x end end

a = Scalar.new
a[] = 42
p a[]

you can see the "[]" as some kind of (postfix) dereference operator, like
the unary "*" in C, or the "${}" in Perl. But here you'd have to put
derefs consistently on anything that needs to be seen as a scalar.

> Probably the main use of typeglobs was for passing filehandles to 
> subroutines

right.

> Can you show an example of a usage of typeglobs in Perl that can't be
> easily mapped into Ruby?

It depends. In the example above, playing directly with the a variable
can be seen as equivalent to a typeglob, while every non-typeglob use
would work with a[]. if you do b=a then b[] is an alias for a[]. but if
you bind your data directly to a and b, they can't be aliased to each
other the way you can do it in Perl, because Ruby cuts on the levels of
indirection. IIRC, most typeglob usages outside of subs and io are closely
related to the notion of scalar.

> >6. In Perl you can modify inheritance on the fly. This may mean deleting
> >superclasses.
> How often is this done in practice?

The only case I've seen of it was a very bad case of arrogance and bad
design. However I wouldn't like to dismiss the feature right away. The
main use would be runtime-reloading, something you'll find Smalltalk fans
and IDE fans are often drooling about.

> >7. Perl's SUPER restarts lookup (Multiple Inh); Ruby's "super" resumes
> >lookup (Mixin Inh).
> How to map multiple inheritance into a single inheritance model with 
> mixin's?  Are there any systematic methodologies for doing this?

They don't map to each other. I mean, there's a half-overlap of MI and MxI
semantics, but in many places where they do differ, there is no way to get
MI behaviour with MxI, or MxI behaviour with MI... MI allows the diamond
inheritance with ability to call the supermethods of your choice; MxI
doesn't give a choice *there*, but instead allows to insert supermethods
in the chain. I really don't see how you can do either with the other
model.

> Yes, this ability for a variabel to trigger method calls based on access 
> to that variable is useful (Perl's tie mechanism).  Aren't there other 
> ways to do this in Ruby?  For example, there's a recently released 
> SignalListener pattern on the RAA, here's a breif description:

SignalListener works at the method level; in Ruby, like in Smalltalk,
there's an inst-var level that cannot be overridden. (the Self language
unifies the two by making inst-vars work through an equivalent of
attr_accessor)

> Or perhaps even the Observable pattern could be used to acheive similar 
> functionality to Perl's tie.

that would be the reverse. tie() is more fundamental than Observable.

> Certainly, it's not as 'light-weight' as Perl's tie mechanism (and 
> therefore performance will not likely be as good) but it seems to be  a 
> way to acheive similar functionality.

This 'light-weight' is in terms of execution time. In terms of
implementation code and use code, it's not exactly beautiful.

If local-vars were just attr_accessor applied to stack frames (the Self
language again), there wouldn't be much of a problem =)

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju