in reply to Hiding Internal Classes ?

Well you can always use things like Class::Object, Class::Classless, and the like.

There was also talk of having support for truly anonymous classes. (In fact Simon Cozens tried to single-handedly add support for that to Perl 5 and was told not to.) I have no idea what current plans for that are supposed to be.

As for better ways, well I like the way that Smalltalk does it (and other languages have borrowed it - I am more familiar with the way it works in Ruby than Smalltalk). In Smalltalk a class is an object. Any variable can hold a class, but normally you would want your classes to be held in global variables. An object belongs to a class. The methods of an object are accessed through a lookup on the class. There is a distinction here between class methods (ie methods of the class object) and object methods (ie methods of the object that is a member of the class).

For instance Ruby has a File class. File has methods relating to files but not a specific file, for instance it has methods for various file tests. When you call File.open you get an instance of class File. This instance has methods appropriate to handling a file, you can read, print, and so on. However it makes no sense to ask a file whether another file exists, so you can't. That isn't an object method. It makes no sense to ask the concept of a File to read the next line. So you can't. That isn't a class method.

Perl confuses object and class methods in a most unfortunate way. However if you wanted to, you could create the above structure in Perl. You could probably do it fairly efficiently. These classes would usually be anonymous. Hmm....

But I won't. Yet.

  • Comment on Re (tilly) 1: Hiding Internal Classes ?

Replies are listed 'Best First'.
Re: Re (tilly) 1: Hiding Internal Classes ?
by John M. Dlugosz (Monsignor) on Jul 11, 2001 at 02:00 UTC
    A class it itself an object: Yes, if blessing (and @ISA) referred to the underlying symbol table hash, rather than it's name, then you could use references to unnamed classes. But the implementation is based on the string, not what it ultimatly resolves to.

    Why?

      Probably because Perl's OO is a hack on top of package namespaces. Constructed at a time when references were still really new in Perl, and nobody knew how useful they would turn out to be or how far they would go.

      And the idea of a class as an object is not part of Perl. Indeed there are many Perl programmers who think it a ood idea to make what I would say should be class methods into object methods. (Yes, I am referring to the testing in new whether you are passed something blessed...)

        If that's the only reason, then maybe Perl 6 will go farther in using references rather than strings for more things. (Any p6p's listening?)