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.

Sorry. I somehow missed this reply.

Nothing new,

True. But old is not a pseudonym for "bad"; much less new a pseudonym for "good".

I already listed this possibility

Yes, you did. But I wonder why you dismiss it so readily?

and BTW wasn't even talking about autobox.

Did you miss the "either objects or" part of my post you quoted?

And was I dreaming when I thought I read: "Another approach would be to use something like autobox" in the OP?

Y'know, I'd really like to qet a squint at whatever piece of code it is, that you've had trouble either refactoring or porting, that prompted your current obsession, investigations :)

---

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.

"I'd rather go naked than blow up my ass"

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! =)

For the record. I wasn't talking about the performance of Perl OOP, but that of autobox. Perl's OOP can be perfectly efficient, provided it is coded to attain its benefits, and not enforce its associated dogmas.

With respect of Working Code First and Tune Later. You do not achieve effective, maintainable, scalable efficiencies by optimising after the fact. That inevitably leads to obscure idioms and unmaintainable hacks that come back to bite you. You acheive it by designing efficiently from the ground up.

Adding layers on top of badly designed code, may bring short-term relief, but they don't last. The earlier in the design cycle that efficiency is considered seriously, the less often it will need to be re-visited. Ignoring the problem from the outset and relying upon Mooore's Law to compensate has been the downfall of so many (large, well-funded and infamous) projects, it really is a surprise to me that the message hasn't got through yet.

As for the rest of it. I realise that you'll say: "This was just an example". But that's the problem with unrealistic examples, they do not stand up to even the simplest analysis.

Any programmer or analyst who cannot foresee that an array is an inadequate data structure for a collection of entities called 'Employees'... Well frankly, perhaps they should consider another careeer.

An array is a numerically indexed collection. The only attribute of an 'Employee' entity that makes even the vagest sense as a numerical primary key is 'EmployeeNo'. But even the smallest of new companies is going to start numbering its employees from something like 100000 or 10000000. To cater for hoped for future growth. And to allow for the inevitable turnover of staff. And other than using the long deprecated and obscure $[, it doesn't make much sense to start using an array from such a high base.

There is simply no correspondance between those operations available on an array, and those that are obviously going to be required--from the very outset--for an 'Employee' collection.  shift might superficially seem like an operation made for discarding an ex-employee, but a) employees don't leave in the order they joined; b) it would cause all the existing employee numbers to change; c)...; d)...; e).... There is just no utility in starting with an array of 'Employee's; never mind trying to extend its operations to the foreseable and inevitable conclusion.

Other than for transient uses--say, sorting a small subset of the collection--using an array for Employee entities is an obvious non-starter.

As for the twigils suggestion. I think you have about as much chance of getting the Perl 5 language redesigned from the ground up, in order to ease the refactoring of broken-from-the-day-it-was-conceived code, as I have of enjoying the first 1/6th gravity orgy on the Moon.

Perl has it all! =)

Not all. But most of what is truely useful. You just have to learn what it has; learn why it has it; and learn how to use it effectively. And part&parcel of that, is learning why it doesn't have certain things that other languages do have. Whilst there are some that I'd put into the 'it'd be nice if' pile, for the most part, the reason it doesn't have them, is because it doesn't need them.

The only answer to the exponential growth in software costs, is for programmers to learn to concentrate their efforts on what is needed. And forget the rest, until it is needed.

---

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.

"I'd rather go naked than blow up my ass"

> An array is a numerically indexed collection. The only attribute of an 'Employee' entity that makes even the vagest sense as a numerical primary key is 'EmployeeNo'.

Oops, true so true, thanx for telling me! :-)

Cheers Rolf

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.

(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