Re: Classes
Ralf wrote:
>>I still believe in the ultimate preproccesing language through. Which =
is
>>based upon context. I dunno, it stills sounds a bit radical. It sounds =
like
>>most of my suggestions for Euphoria I made in the beginning.
After a while, the need to use a pre-processor gets a bit old, even with =
a fast machine. That's the main reason I stopped using PP. I think =
certain ideas (like the 'end' keyword in a slice) are clearly better, =
and people should hammer on Robert until it's added. 
The problem with OOP is you often need the same extention name for =
different classes. For example, COST may mean a monetary cost in one =
context, and a decision cost in another. That's the point I keep banging =
my head against with OOP. I came up with one OOP library that handled =
all the class names and variables as strings, much like X Window =
resources. That way, I didn't have to worry about name collisions. But I =
worried that the cost of doing a find() makes that method too expensive =
to implement, so I didn't use it. I still might come back to it - it =
makes tracing much easier when you have access to names.
I keep wishing I had some FORTH defining words, or different =
dictionaries. The FORTH dictionaries are akin to name spaces. CONTEXT !
>>(integer/sequence/atom/etc. is just a choice of interpretation of some =
data,
>>why not make the choice ourselves.. was one of my ideas.. more than
>>logically it wasn't followed 
)
Well, now that you can allot memory, you can set up pointers and build =
your own binary data to your heart's content.
>All our OOP implementations can only inherit from one other class.
>Lets keep it that way. Multiple inheritmens make spagetti code, I can =
not
>understand why this is included in oo. It's such a hack (i know.. the =
word
>'hack' is my new tick) to make up for the restrictions.
I agree. Most features of multiple inheritance can be handled by setting =
up a composite object. And it gets rid of a lot of the headaches.
>>Well, the old one by Francis Bussiere doesn't even use routine =
pointers.
To be fair, I don't think there were pointers available when his code =
came out. It was a pretty cool demo anyway.
>>And yours and Irv's are backed in your code.
Mine can be pulled out fairly easily, but it's still evolving. For =
example, I keep waffling on how to handle initialization.
>>Not to have another flavor (althrough like everybody, I'm convienced =
my
>>approuch is the best, I guess its just a personal taste.)
You can say that again. Another reason for Robert to make the call. Or =
maybe he can watch quietly from the sidelines, and see what remains =
after a couple of months.
>>I can hardly wait. Your prior blurb looked very interesting. Will it
>>support VGA as well?
>
>Well, like I said it is a bridge. All video modes in Euphoria will be=20
>enabled.
>But all the code and thinking is about the fact that you can "plug-in" =
a device.
>You can quickly create a video device for NGL.
>In fact only having a routine to open the video mode and one to put a =
pixel
>on the screen is enough.
>>The rest is then emulated using the pixel routine.
I had been relying heavily on a bitblt routine for WinMan, until I =
rewrote the logic. Something like that might be useful. The core routine =
was written around get/put_pixel.
>Well, if you combined PP & Dot, added color-syntaxing for them and put =
it on
>as default, many people might use. I know I will. Especially the slice =
looks
>a lot more clear.
We'll see what demand is. For now, they are seperate packages. Despite =
the fact that I just revised PP (I made a bug fix to the CASE =
statement), it's very scary code to get into - there's a *lot* going on =
in there!
-- David Cuny
|
Not Categorized, Please Help
|
|
