in reply to Re^2: Assignable Subroutines in thread Assignable Subroutines
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".
Re^4: Assignable Subroutines
by demerphq (Chancellor) on Jan 25, 2005 at 16:01 UTC
|
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.
| [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 ...
| [reply] [d/l] |
|
| [reply] |
|
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] |
|
This was a getter/setter example, good OO does not use such methods, as it is truly "object oriented".
I must not understand your point. Almost every object ive ever used has properties. In fact this comment is so crazy to me I cant even think of what to say in response.
An object DOES something, you don't manipulate it's properties directly (and that's what getters/setters do, just in a PC way).
Well i dont know where you get this from, it doesnt match up with my experience at all (to say the least). An object is just an encapsulation of data and the methods that manipulate that data. Its like a record that is smart enough to know what subroutines can manipulate it. Property accessors just provide a convenient syntactic sugar for how to pass data into the object and a place to validate it when you have.
Lets bring this back to one of the original uses of OO: representing graphical elements in a GUI. Now say we have a cursor object, how do we change its color without using a property accessor? IME it would normally be done by something like:
$cursor->color(BLUE);
And no, im not going to give you a non getter/setter example, as that is what this thread is all about.
| [reply] [d/l] |
|
|
|
|
|
Re^4: Source filters are *not* evil
by Ovid (Cardinal) on Jan 25, 2005 at 22:47 UTC
|
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.
| [reply] |
|
|