I think "type" is a foundationaly bad idea. What matters is that the object in question can respond intelligently to the message you're passing it. Or at least, that's what I think right now, anyway. It seems like type specification (and as such, early binding) have a very limited real use in the domain of really-actually-for-real-and-seriously mission critical systems, like those that guide missiles or passenger planes.
In the large though, it really seems like specifying type is a lot of ceremonial overhead if what you need to say is really just some arguments to some function, or pass a message to some object. It might help if you explained what you meant by type. If you're thinking of using "class" as type, I expect you'll fail. Asking for an object's class in any case where one is not employing reflection to implement a tool for programmers reduces the power of polymorphism in your program. It can be argued easily that you shouldn't have to worry about type: you should be able to expect that your method's argument is something which sensibly implements a protocol that includes the message you're sending it. If you're talking about primitive types, e.g. a hardware integer/word, or a string as a series of bytes, then I suppose the conversation is different, right? Because if we're talking about machine primitives, we really aren't talking about objects at all, are we? On Oct 8, 2010, at 3:23 PM, spir <[email protected]> wrote: > On Fri, 8 Oct 2010 19:51:32 +0200 > Waldemar Kornewald <[email protected]> wrote: > >> Hi, >> >> On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout >> <[email protected]> wrote: >>> The PataPata project (by me) attempted to bring some ideas for Squeak and >>> Self to Python about five years ago. A post mortem critique on it from four >>> years ago: >>> "PataPata critique: the good, the bad, the ugly" >>> http://patapata.sourceforge.net/critique.html >> >> In that critique you basically say that prototypes *maybe* aren't >> better than classes, after all. On the other hand, it seems like most >> problems with prototypes weren't related to prototypes per se, but the >> (ugly?) implementation in Jython which isn't a real prototype-based >> language. So, did you have a fundamental problem with prototypes or >> was it more about your particular implementation? > > I have played with the design (& half-way) of a toy prototyped-based language > and ended thinking there is some semantic flaw in this paradigm. Namely, > models we need to express in programs constantly hold the notions of "kinds" > of similar elements. Which often are held in collections; collections and > types play together in my sense. In other words, type is a fondamental > modelling concept that should be a core feature of any language. > Indeed, there are many ways to realise it concretely. In my sense, the notion > of prototype (at least in the sense of self or Io) is too weak and vague. For > instance, cloning does not help much in practice: programmers constantly > reinvent constructors, or even separated object creation and initialisation. > Having such features is conceptually helpful, practically secure, but most > importantly brings it as "common wealth" of the programming community (a > decisive argument for builtin features, imo). > Conversely, class-based language miss the notion, freedom to create, of > individual objects. forcing the programmer to create a class for a chess > board is simply stupid for me, and worse: semantically wrong. This prevents > the program to mirror the model. > >> Bye, >> Waldemar > > > Denis > -- -- -- -- -- -- -- > vit esse estrany ☣ > > spir.wikidot.com > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
