in reply to Re: Benefits of everything is an object? Or new sigils?
in thread Benefits of everything is an object? Or new sigils?

> How often do you actually end up wanting to add methods to something that started as a plain old datastructure?

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()

???

Cheers Rolf

Replies are listed 'Best First'.
Re^3: Benefits of everything is an object? Or new sigils?
by Jenda (Abbot) on Mar 02, 2010 at 12:20 UTC

    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.

[reply]
[d/l]
      > 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

[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 );

        [download]

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

        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]

In Section Meditations