in reply to Hiding Internal Classes ?
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.
|
---|
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 | |
by tilly (Archbishop) on Jul 11, 2001 at 06:28 UTC | |
by John M. Dlugosz (Monsignor) on Jul 11, 2001 at 10:11 UTC |