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.

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

Cheers Rolf

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"

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

Cheers Rolf

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"

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.

and your polluting your namespaces...

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

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

Cheers Rolf

BTW: > @employees->list_active

shouldn't be possible ... neither with autobox

According to the autobox manual, it is possible:

Values beginning with the array @ and hash % sigils are passed by refe
+rence, i.e. under the default bindings:

    @array->join(', ')
    @{ ... }->length()
    %hash->keys()
    %$hash->values()

are equivalent to:

    ARRAY::join(\@array, ', ')
    ARRAY::length(\@{ ... })
    HASH::keys(\%hash)
    HASH::values(\%$hash)
[download]

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.

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

Cheers Rolf

If all you have is a hack, then definitely your decision process is simplified. No matter whether you want to hammer down a nail or screw a wood screw ... all you have is that hack. So you can't make a wrong decision.

The decision did not affect just the sigil, it affected the layout of the code! Stuff you would write as a method if you chose to use an object got implemented as a top level function or an unnamed block, ... It's not just what sigil you use for the thing, it's how you treat it.

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