in reply to Re: Assignable Subroutines
in thread Assignable Subroutines

We dont want to use source filters as they are are fundamentally unsafe. In order to implement this you need to be able to accurately determine when an EXPR ends, which isnt going to be an easy source filter to write, and could have bizarre side effects of its own.

We want properties ala VB in Perl. Real nice and simple, not funkyness, no localization, just validation as part of assignment. It doesnt seem like an unreasonable request to me.

---
demerphq

Replies are listed 'Best First'.
Re^3: Assignable Subroutines
by perrin (Chancellor) on Jan 25, 2005 at 15:51 UTC
    How is it different, aside from syntax, from calling a setter method?
[reply]

      How do you do this with a setter method? 

      $obj->thing( 15000, 20000 ) =~ s[something][else]g;

      [download]
      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
[reply]
[d/l]
        I can't tell what that's supposed to do. If it's just combining two setters into one call, I would do this: 
        $obj->thing( a => 1, b => 2);

        [download]
[reply]
[d/l]
Re^3: Assignable Subroutines
by Anonymous Monk on Jan 25, 2005 at 15:51 UTC
    Source filters are unsafe and evil, AND this language feature appears unneccessary. I'd rather not see the language overcomplicated unneccesarily for the benefit of a small few that see it as cool, hence, make it a source filter -- and leave the language clean. BECAUSE it's a source filter, hopefully far fewer people will use the "feature".
[reply]

      Well, id say that if 'necessary'ness is a factor of language design in your world then you should not be using Perl, or possibly that the Perl you would like to use would be a far smaller, simpler and less useful thing than the Perl that I code in is.

      Theres a host of useful things that can come from simple assignable property semantics that are just plain ugly and errorprone currently.

      ---
      demerphq

[reply]

        Agree 100% .. I don't know if I'd use this feature, but it's something other OO languages have, and it's use seems to be more than non-trivial (as examples elsewhere in this thread and the original hopefully prove).

        A question to someone who knows a lot more than I do, how do other languages handle the more complex cases? i.e.

        $obj->method++;

... etc ...

        [download]
[reply]
[d/l]
        This was a getter/setter example, good OO does not use such methods, as it is truly "object oriented". These sort of things are, IMHO, a design smell. An object DOES something, you don't manipulate it's properties directly (and that's what getters/setters do, just in a PC way). Can you give another non getter/setter example?
[reply]
      Source filters are unsafe and evil...

      I strongly disagree with that statement because I've learned to be be suspicious of "all or nothing" dogmatism whether it exists in religion, politics, or programming.

      Source filters are unsafe. Very unsafe. They are not, however, evil. Ignoring the moral implications of your words (because I don't think that's what you meant), source filters can provide a way of significantly easing some coding burdens for features a language does not inherently provide. They can be extremely dangerous when you're trying to do things that are too complicated (such as using them with Perl :), but if you put in the extra time and effort to do one right, the payoff can be huge though one must be cognizant of the inherent risk. The risk/reward ratio is what one must consider here. Not all or nothing dogmatism.

      Cheers,
      Ovid

      New address of my CGI Course.

[reply]

In Section Meditations