|
Re^4: Benefits of everything is an object? Or new sigils?
by LanX (Saint) on Mar 02, 2010 at 12:39 UTC
|
> No. I consider list_active_employees(\@employees); readable enough.
and your polluting your namespaces...
No your not only polluting main:: you have to pollute every package/class which makes use @employees, or you have always to write Employees::list_active(\@employees) or import from Employees!
And additionally you have to build parameter checking to avoid calling list_active_employees with the wrong object.
... but if something was designed and used for a long time as a plain, transparent data structure, then all the code accesses it as such. And does things you would not want code to do with the insides of an object. ...
You're still thinking within the chains of the old functions. If you used everything from the beginning as an object, you'll have no problems to protect the inside afterwards.
That's why I started using Tie in "Phase 2".
Anyway you might get me wrong, I'm not opposed against writing push @$arr,"elem" as long as it's clear that it's nothing else than $arr->push("elem"), so I can have the best of both worlds and stay backwards compatible.
Other languages do this and actually that's already more or less the mechanism behind tie.
Just the interface in Perl is really messy, confusing and obfuscating the code...
| [reply]
[d/l]
[select] |
|
|
and your polluting your namespaces...
This justifiction reminds me of a directive that came around at a company I worked at breifly a few years ago. The directive was that none of the company servers should ever be more than 50% cpu-utilised. Dumb directive you say, but its origins are interesting.
When specing up the hardware for a new purchase of servers, an engineer had specified that they should be capable of running the current workloads for those machines they were due to replace with at least 50% cpu overhead to allow for future growth. Then the company had been taken over, and in the rationalisation a new team was brought in. And the new bean counters read that specification, and their interpretation of it was the directive. Which forced admins to schedule cpu-intensive tasks overnight and at weekends in order to comply, thereby putting unecessary and expensive delays in processes for no good reason at all.
Using a namespace is not "polluting" it. It's just using it. An unused namespace is simply a wasted resource. Pointless in its existance.
Besides which, it is perfectly possible to manage namespaces without resorting to either objects or clever, obscure hacks like autobox.
Emp::listActives( @employees );
No namespace clashes. No weird & fragile syntax. And no 50% to 90% performance penalties.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
> Besides which, it is perfectly possible to manage namespaces without resorting to either objects or clever, obscure hacks like autobox.
Emp::listActives( @employees );
Nothing new, I already listed this possibility and BTW wasn't even talking about autobox.¹
UPDATE:
¹) Using autobox to realize a method list_actives() would just be another way to pollute the namespace, see also ->Re^5: Benefits of everything is an object? Or new sigils?. Autobox has it's strength when calling methods on primitive data structures.
| [reply]
[d/l]
[select] |
|
|
|
|
> Using a namespace is not "polluting" it. It's just using it.
It should be mentioned that you don't necessarily have access to all these namespaces, e.g. because you are working in a team.
And you don't necessarily know which package to use, because your dealing with different companies with different rules for deactivating employees.
Concerning the performance argument of OOP in Perl, IIRC it's true that method calls are 10 times slower than calling directly!
But it's usually better to have working code before you care about performance.
You can still fall back to direct calls if it's recommended after profiling.
IMHO there is even a syntax for this in OO Perl by using a method reference.
$obj_ref->$method_ref()
e.g. in a costly loop, you just need to request the code-reference when initializing, and you don't even need to change the interface of the method you call!
Perl has it all! =)
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
and your polluting your namespaces...
... and here autoboxing doesn't help a lot. Suppose you have autoboxing, and you use that to define @employees->list_active. That means nothing else can define a list_active that acts on arrays1. That's namespace pollution as well, and IMO, hardly better than namespace pollution by exporting functions.
1Of course, one might say "what are the chances someone else is going to define a list_active?", but if that's true, there aren't worries about name space pollution.
| [reply]
[d/l]
[select] |
|
|
Of course! Changing the autobox is comparable to messing with CORE:: or UNIVERSAL:: in Perl or changing the prototype of Array() in JS.
That wasn't my point... I was talking about design decissions an cleaner syntax.
If it's unclear if you will be going to bless or tie a _specific_ primitive array into a class and you wanna stay flexible you will have to use references right from the beginning:
And this will force you into to sigil accrobatics like writing things like push @$ref,"elem"
In this case - i.e. only when dealing with primitives - it's an option to use $ref->push("elem") right from the beginning to have a cleaner syntax. (The resulting caveates like speed punishment are listed in the OP.)
But IF you decide later to extend this class you can _bless_ $ref into a new class with list_active -method, without changing the interface you used and without poluting other arrays.
Anyway my prefered - "utopic" - syntactic solution is to have an extra special sigil for arr_refs, such that you can still write push €ref,"elem" (or even €ref->push("elem") according to your taste) without sigil accrobatics.
This (and other syntactic simplications) would make Perl5 much easier to use and to learn without breaking compability to older sigils. (And would build a migration bridge to Perl6)
Perl forces you anyway to use refs in bigger programs, IMHO there is no big point of @ and % if you can't use them to distinguish the underlying structures.
BTW:
> @employees->list_active
shouldn't be possible ... neither with autobox nor blessing, you will have to write something like
\@employees->list_active
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
You've been poluting your namespaces all the time until you suddenly decided what used to be an array should now be an object. You've been thinking "within the chains of the old functions", not me. You are the one who decided the @employees should be an array, not an object.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
|
|
> You are the one who decided the @employees should be an array, not an object.
Exactly what I'm saying, I took a wrong decision between two options, because I can't foresee the future. (I'm not as gifted as you are ;)
In other languages this "error" is easily corrected without excessive use of extra code and symbols because these two options are unified into one...
... so why not simplifying the interface in Perl?
| [reply] |
|
|
|
|