[ruby-talk:27978] Re: Perl/Python Module Porting (Perl features not found in Ruby)

In article <Pine.LNX.4.21.0112072256020.30424-100000@relayer>,
Mathieu Bouchard  <[e-mail]> wrote:
>
>On Sat, 8 Dec 2001, Eric Lee Green wrote:
>> Only problem with most Perl modules is that they are FAR from being 
>> object-oriented. Thus you can't just take a Perl API and port it to Ruby 
>> (with the exception of the very few Perl modules that are object-oriented). 
>
>I'd instead say that it's because there are a number of Perl features that
>are not found in Ruby:
>
>1. tie(). This takes a builtin type and turns it into an abstract class
>for which you provide an implementation. Ruby has its builtin types as
>ordinary classes, but there's still a mismatch. MetaRuby (see RAA) takes
>care of ARRAY and HASH; but nothing takes care of IO and SCALAR yet. IO
>can be fixed, but...
>

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.

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

>3. In Ruby, there is _no_ equivalent to GLOB. Well, neither in Perl4 nor
>Perl6, but most of Perl code nowadays is Perl5. Many uses of GLOB can map
>to Ruby's "alias", but many can't.

Probably the main use of typeglobs was for passing filehandles to 
subroutines - there are better ways of doing it now (and this isn't an 
issue for Ruby).  The other use is as an aliasing mechanism.  Can you 
show an example of a usage of typeglobs in Perl that can't be easily 
mapped into Ruby?

>
>4. In Ruby, values are passed to functions; In Perl, variables are passed
>instead, though most code revert to value semantics by copying the
>parameters to local vars.

This came up in a recent thread here (look for "References").  It is a 
potentially problematic issue for porting Perl modules to Ruby - Perl 
modules that rely on this feature of Perl will need to be redesigned in 
Ruby.

>
>5. Perl has contexts; most prominently, returning a "list" is not the same
>as returning a "scalar array ref", and returning a "scalar value" is not
>the same as returning a single-element list either.
>

True.

>6. In Perl you can modify inheritance on the fly. This may mean deleting
>superclasses.
>

How often is this done in practice?

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

>8. Perl makes a difference between objects and non-objects; objects
>are implemented on top of non-objects: hashes, arrays, scalars, ios,
>subs, globs; most of those can be in turn "tied" (see #1), which means
>that instance variables themselves may trigger method calls. (I've seen
>this used as a basis for a persistence 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:

"In a nutshell, this design pattern is an alternative to Observable for
purposes of object-to-object communication. SignalerListener offers
the ability to bind specific signals from an object (the Signaler) to
specific procs from another object (the Listener) while retaining the
anonymity of the Listeners. Any number of signals may connect to a single
Listener proc and any number of procs may subscribe to a signal."

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

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.


Phil