I think you'll probably find that the UNIVERSAL class is weaker in perl 6, or at least less UNIVERSAL, than it is in perl 5. That's partially because there won't be a true universal base class for parrot, and partially because there just isn't a real need.

It's important to note, however, that what you're looking for has no business being in any base class. Threading operations are really fundamental language and language engine things, and unless you have a fully OO language (which perl isn't) you're just asking for trouble.

I think you're confusing Macintosh apples with Apple Macintoshes. OO and threads have little to do with each-other. Sure, there should be an easy way of having objects be thread-safe, but that's not a matter for UNIVERSAL, which provides _methods_ that are inherited by all objects. Thread-saftey is going to be more a matter for attributes, and the implementation of attributes is sepperate from the implementation of methods, I belive.

As for tie and overloads, they're likely to be completly different in perl6, almost to the point of unrecognizablity.

As for locks, I don't think there's a clean way of doing that, quite simply, without real support for that in the implementing code. There isn't a magic way to say :lockable, because that means different things for different implementations.

Multi-thread support should be built into UNIVERSAL, instead of being put into threads and threads::share. This would make it much easier for designers to design multi-theaded OO program in a more integrated way;.

Why?

I don't mean to sound facetious, but I don't see any gains in moving thread handling into UNIVERSAL. What behaviour would you like to see? What would be made easier?

As for moving tie to UNIVERSAL I don't understand how this could possibly work. There isn't a single "UNIVERSAL" tie interface - they are separate for scalars, hashes, etc.

Can you give some examples of what you would like to see?

Mild correction, BTW. UNIVERSAL is the same for all class implementations; they're methods UNIVERSAL to all objects, and an object is just a blessed reference--to anything. There's also only one tie, but different TIE* methods.

theorbtwo corrects his typos from tye to tie.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Fair point :-)

What I was trying to say (badly) was that I didn't see how tie and UNIVERSAL would fit together.

1. Not all objects are tied objects and need to support the tie methods - so it doesn't make sense for them to be UNIVERSAL
2. Tied scalars, arrays, etc. are different and support different methods - so having them all inherit from the same class doesn't make a lot of sense either

I guess you could argue for a virtual class Tied, with subclasses of Tied::Scalar, Tied::Hash, etc. but it's probably not worth the effort, and would annoy the people who don't think of tie in an OO way.

...support the concept of interface just like those typical OO languages do.

Be careful with your broad generalizations. At least one "typical" OO language I commonly use does not have interfaces. Other than that, I agree with most of the other posters in asking "Why?" and stating that "UNIVERSAL is not the place".