in reply to Re^6: Benefits of everything is an object? Or new sigils? (performance)
in thread Benefits of everything is an object? Or new sigils?

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.

That's a Straw man. Nowhere in the discussion from the OP up to BrowserUk's neither team work nor "teams owning namespaces" have been mentioned, and by producing them you don't address any point of BrowserUk's post.

Apart from that, you deny having mentioned autobox when you clearly did so in the OP -

(Of course it would be nicer if tieing and blessing of primitives could be unified into one interface like the one showed in autobox ... please note: JS has internally primitives, only the interface is OO)
- and claim to have addressed the fully qualified subroutine call, when you didn't.

That doesn't further a interesting dicussion

Namespace pollution... there's no pollution neither if the oil stays in the gas refinery, nor when it is shipped to fuel cars. Pollution happens if the gas refinery or the cars leak oil. Namespace pollution happens when a module exports symbols into other namespaces without being requested to do so. See Exporter.

  • Comment on Re^7: Benefits of everything is an object? Or new sigils? (straw man)

Replies are listed 'Best First'.
Re^8: Benefits of everything is an object? Or new sigils? (performance)
by LanX (Saint) on Mar 02, 2010 at 17:32 UTC
    (UPDATE:)

    > That's a Straw man. Nowhere in the discussion from the OP up to BrowserUk's neither team work nor "teams owning namespaces" have been mentioned, and by producing them you don't address any point of BrowserUk's post.

    This whole thread is about reliable code design which survives unforeseeable future developments! (\UPDATE)

    >Apart from that, you deny having mentioned autobox when you clearly did so in the OP -

    In the OP I was listing autobox as one of the possibilities to achieve an object. Down this thread I was talking about blessing, autobox doesn't bless, it was all about generally turning an array into an object.

    # Another approach would be to use something like autobox and to always have objects right from the beginning and to write $employees_ar->push() !

    But that's

    a) not very perlish and

    b) not faster than overwriting CORE::push (I think even much slower)

    But this shows the benefit of everything is an object that other languages have!

    (added underlining to make it clearer)

    So please explain, what was BUK telling as new, if he is only referring to the OP ? (And BTW autobox - which is not the primary subject of this thread about code design -but BUK's - is according to the docs only a little slower than method calls on blessed objects! )

    > and claim to have addressed the fully qualified subroutine call, when you didn't.

    I did, in the post BUK was replying to.

    or you have always to write Employees::list_active(\@employees) or import from Employees!
    (added underlining to make it clearer)

    > That doesn't further a interesting dicussion

    O ... your post certainly does.

    Cheers Rolf

[reply]
[d/l]

In Section Meditations