00:00:00 --- log: started forth/01.09.10 01:18:59 * aaronl is away: irc sucks 02:02:38 * aaronl is away: sleep 04:10:41 --- join: MrReach (mrreach@209.181.43.184) joined #forth 04:10:46 hihi! 04:26:14 hoi mrreach 04:26:37 this is an independant implementation 04:26:42 not the one i worked on 04:27:16 (even if it credits me, i've done nothing to this version) 04:27:29 but this is the free version 04:27:30 ok 04:27:40 contrary to the one i worked on 04:27:43 why did the design team choose the sytax? 04:27:51 java ancestry 04:27:57 ack! 04:28:08 desingn team were 2 people 04:28:13 (me one of'm) 04:28:15 have you examined Swiftforths syntax? 04:28:19 no 04:28:29 clever, if not a bit complex 04:28:50 other team member is a java-to-forth convert 04:29:10 durring the declaration of an object, it's like a brand-new user-variable space is created 04:29:23 for instance data ? 04:29:30 yes 04:29:51 so CREATE VARIABLE 2VARIABLE ALLOT all work as expected 04:30:13 but are object specific 04:30:19 we had good reason to embed instance data into the memory range occupied by whole object 04:30:28 and not seperate it 04:30:42 (embedding objects into objects into objects) 04:30:55 you mean rather than seperate allocations for each local variable? 04:31:28 we could have (actually had to have) an object, in which instance data space more objects could be created. 04:31:36 that would make good sense ... objects are supposed to be "grown" incremently, each class adding a bit of data and complexity 04:31:53 oh, ok 04:32:14 (partition objects, directory objects, file objects) 04:32:19 why do that rather than "pointer to object instance data"? 04:32:41 because partition objects reserves and provides available disk space 04:32:57 and directory objects create and reserve file object space 04:33:18 oh! you were writing an OS? 04:33:21 yes 04:33:34 bet THAT is/was an interesting project 04:33:52 indeed. only, more time went into developing the oo model, rather than the file system 04:34:07 (which still is interesting of course) 04:34:29 interesting ... you defined an object that encompassed the entire disk subsystem? 04:34:33 yes 04:35:10 how is that more advantageous than defining such things as "directory record" "file record" etc? 04:35:42 some file types support records. 04:35:59 I meant for the heirarchy 04:36:01 the os wan't invented by us, but reimplemented using oo 04:36:11 ok 04:36:13 we sticked to those specs 04:36:27 may I ask which filesystem? 04:36:44 go to icq ... 14:59:02 --- quit: MrReach () 15:11:18 --- join: MrReach (mrreach@209.181.43.184) joined #forth 15:11:27 I awake now, Speuler 15:12:33 you took a long nap 15:12:52 9 hours 15:14:15 blah 15:14:42 stupid people, I'm sleeping during the day and every salesman in this part of the country decided to work this neighborhood 15:14:51 i haven't been sleeping at all during the last nine hours :) 15:15:12 * MrReach mumbles, "I'm going back to bed now. Have a nice day." 15:15:31 double glass ? 15:15:49 keeps the noise out 15:15:51 ok, so what are the desireable characteristics of a Forth OO package? 15:16:05 that it is smaller than 2 kb 15:16:08 they were buzzing the doorbell, which makes the dog go ballistic 15:16:13 quicker than asm 15:16:14 HAHA! 15:16:48 I hope those are ideals and not design requirements @:^> 15:17:10 it says "desirable" 15:17:16 do you mean quicker to code than ASM or faster calls than ASM? 15:17:28 fair enough 15:17:28 both of course 15:17:45 ok, is data hiding a must? 15:18:24 it shouldn't restrict the experienced programmer but keep the unexperienced from doing stupid things :) 15:18:30 i suppose so 15:18:43 but that depends whom you ask 15:19:34 generally, I support strick data hiding 15:19:46 strict ... maybe not as awake as I thought 15:20:01 is early binding a must? 15:20:11 I generally consider it to be 15:20:15 i wondered already how you hide data, using a rope 15:20:30 beg parden? rope? 15:20:44 strick = german for rope 15:21:00 heh, well of course someone who knows the internal workings of the object system can hack at it 15:21:14 HAHA! 15:21:16 sure 15:21:35 so the "experienced programmer" shouldn't really be a concern 15:21:43 but probably isn't supposed to 15:22:24 why would one use oo anyway ? 15:22:51 to protect the data 15:23:16 only "authorised" routines allowed to work with instance data 15:24:05 for operator overloading ? 15:24:55 to communicate a software design ? 15:24:58 that is another possibility 15:25:18 but overloading is not such a great advantage with forth, which makes overloading easy anyway 15:25:27 does it ? 15:25:40 how many uses do you have for "open" ? 15:25:54 or "fetch" ? 15:25:55 yes, conceptualizing an app as objects helps the top-down design 15:26:34 lots and lots for "open", "fetch" also 15:26:46 how do you overload those ? 15:26:57 but because of the way forth is, I have to come up with a different name indicating the data type 15:27:23 but, that's nt overloading an operator 15:27:25 I was thinking of the case where a word is redefined to add functionality to it 15:27:35 that would be overloading 15:28:15 i assumed overloading to mean "having multiple meanings, depending on context" 15:28:33 ok 15:28:44 that's what i consider oo to be good at 15:28:50 that is what I meant 15:29:12 "open" might initially work with files only ... might later be extended to handle network sockets 15:29:23 for the conceptualisation, a paper oo could be sufficient. 15:29:34 that is true 15:29:59 inheritance of data, or methods, can be a useful thing too 15:30:14 EXTREMELY useful 15:30:28 inheritance, then is desireable 15:30:44 agree 15:30:46 what about mult-inheritance? 15:30:57 can of worms, but still useful 15:31:04 i'd try to avoid unless no way around. 15:31:06 pain to implement properly 15:31:53 may have quite an impact on run-time performance too, because of more complex cast check 15:32:12 MIGHT 15:32:40 I usually try to ensure that any type checking occurs at compile time 15:33:11 :: foomethod anyobject get dosomethingwith ;; 15:33:49 how to compile-time check that dosomethingwith is legal method on object gotten with anyobject get ? 15:34:40 you could as well compile-time optimize arithmetic, by replacing the calculation with postpone literal 15:35:29 (just compile the result, instead of the calculation, i mean) 15:35:37 yes, and some compilers do just that 15:35:39 more or less same problem 15:35:57 when it can be equated to a literal 15:36:18 if working on literals, ok. but run-time generated values are hard to catch 15:36:32 please meet me on teamwave in room "objects" 15:37:11 i think my teamwave client is gone. 15:39:46 oh, ok 15:40:50 i'm in need of a coffee 15:41:43 ok 15:44:51 out of filters ... 15:45:22 bummer! 15:45:27 paper towels? 15:45:38 i've settled for tea instead 15:45:44 fair enough 15:46:03 got an espresso stand around the corner? 15:46:18 yes. but not at this time 15:46:35 that was cool when working at GSJN ... an espressso stand in the lobby of the building 15:47:12 10 to one a.m. 15:47:23 yup 15:48:01 how can you get the advantages of oo w/o the negative sides ? 15:48:01 microsoft had an interesting idea with COM objects ... 15:48:09 hmmm ... 15:48:15 what are the negative sides? 15:48:25 have to reorient thinking, for one 15:48:32 1. size 2. speed. 3. alien code 15:48:59 I don't see that OO _HAS_ to be larger or slower than procedural code 15:49:16 much larger or much slower, in any case 15:50:09 has some overhead. method tables, for example 15:50:13 there could be token tables for quick lookup 15:50:17 heh 15:50:25 great minds 15:51:25 in heritance can make lookup tables complex 15:52:20 it may not be good practice, creating classes w/ just one single instance, but in such a case, overhead increases 15:52:34 that is true 15:53:05 as more instances a class have, as better the overhead is spread out 15:53:16 also, memory use increases exponentially to the inverse of the number of instances 15:53:23 heh 15:53:33 not really. 15:54:19 1 whole def for 1 instance, 1/2 for 2, 1/3 for three ... right, not exponential 15:54:32 class does only maintain class instance data, but does not allocate memory for instance instance data ... only when instance is created, is memory alloted. 15:54:35 plus instance data 15:55:06 meaning: instance data of class is different from instance data of instance of class 15:55:17 yep 15:56:03 (assuming a class is an object too) 15:56:34 when working on an app in Win32Forth ... changing to OO methodology greatly simplified code 15:56:50 even though I consider win32forth object system to be badly broken 15:57:23 is nicely colorful, though 15:57:50 but , what is a word in another forth, is an app in win32forth 15:57:54 * MrReach laughs and spews coffee. 15:59:41 i met the authors of both gforth and bigforth when i was in munich 15:59:52 have you reviewed how microsoft implements COM objects? 15:59:58 oh! cool! 16:00:20 Bern Payson and .... erm 16:00:26 Anton Ertl 16:00:30 knew it would come 16:00:33 nowadays jens wilke. 16:00:59 anton i met a few years ago. (euroforth). jens and bernd recently. 16:01:21 bet the talk was interesting 16:01:32 Forth people tend to be quite strange 16:01:32 jens almost every day, bernd once a month 16:02:01 jens is not too strange 16:02:16 have you reviewed how microsoft implements COM objects? 16:02:26 DCOM, or just COM ? 16:02:33 either, really 16:02:40 almost identical, I think 16:03:01 had a short look at those a few years ago, but have supressed any memory 16:03:20 probably because it said "microsoft inside" 16:03:25 isn't DCOM the same as COM, except some rules about how to pass data for marshalling? 16:04:28 D for distributed components object model works across networks 16:04:32 well, it seemed pretty slick, though it doesn't apply to forth OO directly 16:04:36 yep 16:05:22 the idea was that when you invoked a method, you never knew if it was running in your own context, in a different process on your machine, or on another machine altogether 16:05:35 objects from the company who brought us the blue screen ? 16:05:49 oh, stop, SUN was involved, too 16:05:56 a whole slew of companies 16:06:11 sun brought as java, thats almost as bad :) 16:06:15 Apple, too, I think 16:06:52 anyway, when you have an instance, you have a pointer to some data ... 16:07:05 the method could find out on what object it is supposed to execute i would guess 16:07:08 the data is totally opaque, except for the first four bytes 16:07:28 which you know to be a pointer to a table of execution vectors 16:07:52 the method xt ? 16:08:11 that table is forever fixed for that "interface" to the object instance 16:08:16 yes, the method xt 16:08:55 an object can expose more than one interface, i.e. more than one vector table 16:09:03 and that is how revisions are done 16:09:44 yes, the code expects the original address on TOS 16:10:13 each instance has an own pointer to method table ? 16:10:18 what is after the pointer to the execution table is up to the object 16:10:29 yes, that is correct 16:10:36 if simplistic 16:10:40 and a class pointer too ? 16:10:52 no 16:11:08 an instance pointer 16:11:13 object doesn't know its class ? 16:11:18 heh 16:11:40 ok, you instantiate an object, and now you've got a pointer, right? 16:11:56 possibly. 16:12:04 depends on your model 16:12:29 ok, you know that the pointer points to some blob of data, but you don't know what that data is, except for the first four bytes 16:12:40 ok 16:12:43 I'm talking COM model at this point 16:12:59 you know that those four bytes point to the execution table 16:13:06 ok 16:13:27 you also know that the first adress will do "X" when called 16:13:35 and that the second will do "Y" 16:13:38 initialize, probably 16:14:03 don't know what the second does 16:14:38 actually, the three first ones are always "AddRef" "QueryInterface" and "Release" 16:14:51 which are used to determine when the object dissolves itself 16:15:22 ok 16:16:09 one an interface is published (that is, the effect of calling the xts is known) ... it is forever set in stone 16:16:17 once an interface 16:16:33 but, a given object my support any number of interfaces 16:17:30 so, as the software implementing an object evolves, more functions are added to new interfaces, which use seperate method tables 16:17:54 internally, a new interface may use the code of previously existing interfaces, but you can't know that 16:18:53 i'd feel more comfortable with the idea that the class hosts the methods, and the object is just an instance of that class, able to call upon those methods by knowing its class 16:19:04 this way, you know that if you have interface X of object Y, you will ALWAYS have those methods available to you, and they will ALWAYS perform as advertised 16:19:27 but giving individual objects own method tables sounds like something memory intensive to me 16:19:44 heh, no, it doesn't work that way 16:19:58 each instance contains ONLY a pointer to the table 16:20:03 not the table itself 16:20:18 one table could be shared among hundress of instances 16:20:24 hundreds 16:21:10 if you give method table Y to object X, how can one be sure that methods of Y match instance data of object, fit for methods X ? 16:21:43 ok, the forth code to call the 5th method in the table would look like ... 16:22:37 : test ( ob-ptr -- ... ) dup @ ( now have xt table pointer ) 5 cells + @ execute ; 16:23:05 because the instance itself has a pointer to the correct xt table 16:23:30 and all the methods expect the address of the instance data on TOS 16:23:41 the same address used to look up the table 16:24:09 but, when i use another method table on object, i can't be sure that: 16:24:36 1. desired method corresponds to method xt in that slot 16:25:00 2. method in that slot deals correctly with my instance data 16:25:25 after all, it could be any method table i plug into object 16:25:28 it is FORBIDDEN to use the documentation of any interface than the one you've been given 16:26:00 what is is good for, in that case, to use methodtable Y instead of X ? 16:26:05 if you need another interface to that object, ask for it using method 2 "QueryInterface" 16:26:33 it will give you a new object pointer, which points to a different xt table 16:26:49 but uses the same set of object data 16:26:54 stop. what method xts are in that different xt table ?? 16:27:16 those are defined by the documentation of the new interface 16:27:38 they may be exactly the same, an extension of the prev interface, or completely different 16:28:34 could i use "different xt table" on/with an object with different instance data organisation ? 16:28:48 if you try to use an interface incorrectly, you're gonna get bombed 16:28:51 yes, you can 16:29:05 producing garbage, in that case 16:29:10 no, you can't 16:29:11 heh 16:29:20 ok ... 16:29:35 the object itself points to its XT table 16:29:55 we got an extra level of indirection there: 16:30:07 object points to class, class pointes to method table 16:30:45 (but we can produce garbage too: by telling object that it - now - belongs to another class ...) 16:31:11 well, we would have to go out of our way to do that 16:31:27 by getting adr-xt-table from another object and trying to use it 16:31:59 how would the object know its class ? 16:32:06 ok, to make my previous definition more versatile ... 16:32:23 this one calls the nth execution vector ... 16:32:56 : test ( meth ob-ptr -- ... ) dup @ ( now have xt table pointer ) rot cells + @ execute ; 16:33:10 now, methods can be defined as ... 16:33:50 * aaronl is back (gone 15:14:50) 16:34:14 0 constant AddRef 1 constant QueryInterface 2 constant Release 3 constant soSomething 4 constant doSomethingElse 16:34:39 using method offset instead of method id would save some run-time overhead. 16:35:04 wb, aaronl 16:35:51 it is important to note that COM is a binary interface ... it is not an object system, per se 16:36:21 (we used wordlists for method names, those being the equivalent of 2constants: method id and class-of-method ) 16:36:43 hi MrReach 16:36:52 again, should be method offset instead of method id 16:37:10 cheaper, runtime 16:37:19 well, yours if a forth-tailered construction, COM is not 16:37:27 yours IS 16:37:44 principles are language independant 16:38:35 tables and pointere pretty much too 16:38:38 pointers 16:39:09 yep 16:39:14 probably could have written the same model using basic, or even cobol :) 16:39:27 that is why they were careful to avoid any language specific syntax 16:39:43 yes, there is a VBasic example of how to use COM 16:39:50 not that it would be an improvement in terms of speed 16:40:17 MrReach: you're using many dirty words today 16:40:26 heh 16:41:14 well, I *LIKE* the way COM works 16:41:32 simple, fast, fairly bullet proof 16:41:43 you can still screw it up, of course 16:42:31 and so can the object implementor, but mispublishing what the methods expect on the stack, or what they do 16:44:05 how does DCOM differ from COM ? 16:44:28 but say I have a "database" object ... and a "queryDatase" method ... it can actually be running anywhere ... it is up to the internals of the object to get the data to the correct machine 16:44:44 not sure, haven't read over the spec 16:45:09 but probably provides a uniform method of establishing which machine is the correct server 16:45:16 "internals of object" = "methods" ? 16:45:21 yes 16:45:35 and the structure of the object data 16:45:44 and where that data is located 16:46:08 makes sense, to stuff that bit of knowledge into methods/ 16:47:00 well, for example ... I led on that that objects data immediately follows the pointer to the xt table 16:48:00 that would be very awkward, because can have more than one interface to an object 16:48:28 so it's (probably) implmented that what you get a pointer to an 8-byte structure 16:48:45 the pointer to the method table, and the pointer to the object data itself 16:49:25 why would the object need pointer to data if the class knows object instance data origanisation ? 16:49:48 because there might be more than one interface to an object open at once 16:50:21 which one mean two object pointers, each pointing to seperate method tables 16:50:38 that shouldn't influence instance data position 16:50:46 but it's the same object, and both pointers need to reference the same data 16:51:01 the methods reference data. 16:51:24 those methods could get instance field offsets from object's class 16:51:27 correct, and the only way it knows where that data is ... is by looking at the pointer on TOS 16:51:49 oh! no, i was talking about the blob of instance data 16:52:04 so am i 16:52:30 ok, let's use a simple, lame example ... a "stack object" 16:52:35 two instances of the same class have the same instance data layout, right ? 16:52:52 orginally, its interface consisted of 7 routines ... 16:53:22 AddRef QueryInterface Release Push Pop Shove and Yank 16:53:28 follow so far? 16:53:31 sure 16:53:38 now, that interface may NEVER change 16:53:58 it has exactly that many routines, and they do exactly as advertised 16:54:22 but later, the authors decided they needed to add and delete stuff in the middle of the stack 16:54:26 (of course you may overwrite methods, that doesn't count as "change interface", right? ) 16:54:48 so long as they behave EXACTLY the same, it doesn't matter how they're implement 16:54:49 ed 16:54:53 but later, the authors decided they needed to add and delete stuff in the middle of the stack 16:55:13 so they write "Delete" and "Add" methods 16:55:35 but they can't add them to the current interface ... so they define a new interface 16:56:11 stop 16:56:22 but these programmers are inexperienced, and they make a lame descision ... the new interface only contains AddRef QueryInterface Release Delete and Add 16:56:28 ok, stopped 16:56:45 why shouldn't they be able to add them ? with new method ids at the end of method table ? 16:57:44 because M$ was having probs with installing new DLLs, actually ... the new DLL support the same function calls, but behaved differently, thus breaking all programs that used them 16:58:18 so the standard specifies, one an interface can be used with an object, it can ALWAYS be used with that object 16:58:32 and it's ALWAYS used the same way 16:59:00 thats religion ? 16:59:11 erm ... it's common sense 16:59:44 now, the XTs in a new interface may be the same as an already existing interface 17:00:09 but the COM user doesn't know that ... just fetches the proper XT and calls it 17:00:33 does this make sense to you? 17:01:02 it adds some bloat, because adding new functionality means building a new table 17:01:09 most of it does. i'm missing something: what causes the method table to switch ? 17:01:23 getting a new interface to the same object 17:02:01 oh! wait! a new xt table may not be needed! 17:02:20 if the new interface merely extends a previous interface ... 17:02:36 then the extra XTs can be added to the end of the table, as you suggested 17:02:48 but the users of the earlier interface will never use them 17:03:05 and both interfaces can use the same XT table 17:03:17 sounds plausible 17:03:33 that's for extension only, though 17:04:25 each documented method must retain the same functionality - not much to change there 17:04:27 and each interface pointer would be different 17:04:54 hence the need to have the data pointer immediately following the pointer to the XT table 17:05:25 i still don't see the need for the instance data pointer 17:05:45 because I might open two completely different interfaces to the same object 17:05:59 each would point to a different XT table 17:06:08 I can use both simutaneously 17:06:24 with the same instance data, internal to the object 17:07:14 what follows the pointer to the XT table we can't know, and it might well be the actually instance data (in simple objects) 17:07:23 actual 17:07:42 i don't see the logic in "you need pointer to instance data because you can use two method tables simultanuously") 17:07:57 but, if there's more than one interface, the instance data will have to be independant of the interface pointer 17:08:09 you could use several method tables w/o pointer to instance data, too 17:08:31 yes, if the objects all used exactly the same instance data 17:08:45 no, only those of the same class 17:08:55 yes, that is what I meant 17:09:11 but we might want two "stack objects" 17:09:19 seperate from each other 17:09:28 i assumed that would be the case. what else is inheritance of data good for ? 17:09:34 and we might want both interfaces open to each of them 17:10:00 sho determines layout of instance data, if not the class ? 17:10:22 don't forget, this is a binary standard on how to interact with objects ... not anything about how those objects are implemented 17:10:43 how could two objects of same class have different instance data layouts ? 17:10:44 ok, back to the stack example? 17:11:11 they don't, but they might very well have seperate sets of methods to maniuplate that data 17:11:42 the audio classes in M$ come to mind 17:11:55 wouldn't it make more sense then to make them instances of different classes then ? 17:12:22 no, because they operate with EXACTLY the same data ... just different aspects of it 17:12:41 subclass, and overwrite methods 17:13:25 in the audio example, one interface is used to specify the filename (.snd .mp3 .wav etc) and to play pause stop 17:13:56 another interface is used to setvolume setsurroundattrs etc 17:14:09 ... class soundfile soundfile class snd soundfile class mp3 soundfile class wav 17:14:26 they both work with the same blob of data, but require seperate XT tables 17:14:48 soundfile increasevolume 17:15:33 the sound object might indeed use a class type for each extension ... but that's none of our business 17:15:47