Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Perl 6 'is dim' point

by John M. Dlugosz (Monsignor)
on Aug 19, 2003 at 21:23 UTC ( #285042=perlmeditation: print w/replies, xml ) Need Help??

I was just reading Exegesis 6 and got to thinking...

If declaring something using is is like current tie in that it specifies the backing implementation of something (as opposed to the logical domain), how does is dim(2) fit into things? Rather than the name of the tie-ing class, it's giving parameters or pragmas to the built-in implementation.

Then it occured to me: it works if the built-in class isn't called Array but rather called dim! That is, it ties it to the implementation called dim which takes a list of numbers as parameters.

So, is that elegant or kinky? I think it's trying to be a more general mechanism, just like how use is today more general but can be fundimentally seen as an inclusion mechanism.

The only thing is explaining something like that. use is taught to be for pragmas (arrange your file this way to implement one) or modules (arrange your file that way to implement one) and a naming convention to help the use-er know which to expect.

So, if is dim(2) is "different" than is Foo even though it uses the same underlying implementation with different combinations of other features (e.g. it derives from a built-in class and acts as an alias for it with simplified parameters), I think that needs to be clear up front. In this example, I feel more like it's changing a property of the regular type rather than specifying a different type. Does one (in the current state of the specification) use is to specify properties, as well as using the same keyword to totally change the underlying type? Perhaps that's the key, and also explains why it's using parens instead of square brackets.

Replies are listed 'Best First'.
Perl 6 property mini-tutorial
by TheDamian (Priest) on Aug 20, 2003 at 20:59 UTC
    The is keyword tells a declaration that it has certain properties. The behaviour of each of those properties is specified as a distinct class (hereafter called a "property class"). A property class has certain special methods (hereafter called "property methods") that determine what effect the property has on the referent to which it is applied.

    So, for example, a built-in property class like class dim has property methods that modify the dimensionality of the underlying Array referent that an is dim property is applied to.

    Whereas a built-in property class like class constant has property methods that modify the writeability of the referent that the property is applied to.

    Similarly, a user-defined class such as class Persistent might have user-defined property methods that modify the persistence behaviour of any referent to which the is Persistent property is applied.

    If a user-defined class (say, class Foo) doesn't have explicit property methods, it automatically has implicit property methods (which it inherits from the Class meta-class). Those inherited methods cause class Foo to modify -- in one of two ways -- any referent to which the is Foo property is applied.

    If is Foo is applied to a class (say Bar), class Foo's property methods add Foo to the list of class Bar's ancestors. Thus:

    class Bar is Foo {...}
    is how we do inheritance.

    On the other hand, if is Foo is applied to a non-type (say $bar), Foo's property methods replace the implementation type of $bar (i.e. Scalar) with the implementation type Foo. Thus:

    my $bar is Foo;
    is how we do tying.

    So this one property mechanism gives us a wide range of useful language features (i.e. type qualification, referent modification, inheritance, tying) from a single underlying behaviour (namely, apply certain methods of this property class to the referent of this declaration).

      Thanks for the additional information.

      I suppose the "property methods" basically is a function that is given the thing to which it is applying, and it can monkey with it any way it wants.


        Yes, exactly. Each property method is a method (i.e. an class-specific function) that can be set up to do a particular kind of monkeying with the referent to which the original property was applied.

        The two main advantages of encapsulating these functions in classes are that anyone who is defining a property can provide state (i.e. class attributes) for that property if necessary, and can also create sets of related properties using inheritance.

        A more subtle advantage is that using a class-based interface for specifying properties gives us a clean way to extend that interface at a later time, should we miss some useful feature in the initial design.

Re: Perl 6 'is dim' point
by perrin (Chancellor) on Aug 19, 2003 at 21:41 UTC
    You're right, Perl 6 is looking a bit dim. Better go and polish it again.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://285042]
Approved by liz
Front-paged by broquaint
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2018-04-20 21:03 GMT
Find Nodes?
    Voting Booth?