When it happens and you need to refactor the code, it's a real pain in the @$$ ...

I think you don't see this situation, because you already incorporated all the ugly workarounds necessary.

> I think you invent a convoluted solution to a convoluted example.

Nope, actually I am spending lot's of time planing in advance to avoid this situation. (And I don't think I'm alone)

Other can just calmly start to code and easily react afterwards. That's one of the big advantages of OOP.

> Get it by tied(@array) and call whatever you need on that.

OK so I can extend the tied package with methods intead of creating a new one... well certainly an improvement. Thx! 8)

But do you really consider writing something like this

 tied(@employees)->list_actives()

to be more readable than

 \@employees->list_actives()

or even

 $employees_ar->list_actives()

???

No. I consider list_active_employees(\@employees); readable enough.

You have to invest some time at the beginning to design your data structures and objects and decide what should be an object and what should not. If you do and use objects whenever you are not sure a plain old datastructure is enough, then you should be fine. And if you find out later that something should have been an object, then the fact whether you can attach a method or two will be the least of your worries. Sure, it might have been made easier to do so, 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. So you either refactor properly or end up with something that's treated neither as an object nor as a datastructure.

Jenda
Enoch was right!
Enjoy the last years of Rome.

> 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...

Cheers Rolf