Ed wrote:

   > Any ideas on how to handle this with the 'is' keyword? I was
   > reading the slashdot comments to Exegesis II, and this seemed to be
   > the one issue that had merit. A couple of the posters bemoaned the
   > fact that they were debugging PL/I about 25 years ago, and had code
   > that depended on some obscure property being set somewhere earlier,
   > which affected the code 1200 lines later.
   > 
   > I could see that being a problem:
   > 
   > undef $fh;
   > 
   > $fh is true;
   > 
   > ... 1200 lines later...
   > 
   > if ($fh) { print "HERE!!!\n"; }
   >
   > In other words, 'is' seems to me to be a generous helping of
   > action at a distance. 

I don't see that at all. We're simply providing one more
way for a value to be true, and one more way for it to be false. 
You might as well argue that the following is "action-at-a-distance":
   
    undef $fh;
    
    $fh = "0 but true";
    
    ... 1200 lines later...

    if ($fh) { print "HERE!!!\n"; }


It's probably just a matter of coding what you actually mean. In Perl 5
and 6 your version means "if $fh is true in *any* possible way...",
whereas you seem to want "if $fh is defined", which is:

   if (defined $fh) { print "HERE!!!\n"; }

in both Perl 5 and Perl 6.


   > Is dumper going to become a built in keyword to handle this sort
   > of thing?

Huh? I don't see the connection.


   > Also, what's the difference between a 'property' and an
   > 'attribute', ie, are:
   > 
   >    $fh is true;
   > 
   > and 
   > 
   >    $fh.true(1);
   > 
   > synonyms?

No. The former means:

        "Set the true property to 1 and return an alias to $fh"

The latter means:

        "Attempt to call the C<true> method of $fh. If there is no such
         method, set the true property to 1 and return that value"
        
   
   > Can 'undef' valued thingys have properties

Yes.
   
   > and functions?

No.

   > And are the traditional data elements of a scalar (like value)
   > simply attributes of a universal scalar object?

No.

Though the operations on a scalar might well be methods of the SCALAR class.


   > And if all of the above is true, what does this do to the size of
   > the internal representation of a scalar?

In the worst case, it adds a single pointer to it. But it's entirely
possible that properties would be stored centrally, in which case
there's no impact at all.

Damian

Reply via email to