Type parenting
Blitz3D Forums/Blitz3D Programming/Type parenting
| ||
| Continued diversion from http://www.blitzbasic.com/Community/posts.php?topic=97635 So, lessee... If I understand you correctly, Yasha, a Type is represented by an integer handle much like any other memory item in Blitz? Therefore I could, for instance, create a bank as a Type field, and then add as many children as necessary with no preset limit by adding their integer handles to the bank one (four bytes) at a time, and then loop ONLY through those specific Types? |
| ||
| Yes that is exactly correct and is what I do quite often...banks are great for your own data structures...especially with blitz's handles just being an int....not exactly safe but very useful nonetheless. |
| ||
| (Side note: this will go much easier if you don't refer to objects as "types". A type is a structure pattern, not a thing you can create. Yes a lot of people on these boards call objects types... that just means that a lot of people are 1. wrong, and 2. making the discussion very confusing, because now "Type" means two things.) That is certainly a thing you could do, with one added layer of indirection: you have to use Handle <object> to get the Poke-able integer handle and Object.MyType <int handle> to get the actual instance back again. While in-memory handles are the same four-byte reference as entities and other memory objects, the language's "type safety" prevents you from getting this pointer as an integer, to prevent you doing damage with it ("Handle" generates an indirect reference unrelated to the object's memory location). This also means that when you want to get the object out of the bank again, you must know the right type to cast it back to with Object (or you'll get Null). But the short answer is yes: the bank then becomes a simple array of references. It's semantically more or less identical to this: Field notABank.MyType[LENGTH] ...except of course with flexible length. You're doing the exact same thing as PeekInt-ing entities or images into a bank. |
| ||
| Good lord. Finally After all this time And nine years of Blitz At last I have understood the mysterious, undocumented Handle and Object commands. Tears of joy have been shed. ;_; Anyway, that aside, thanks; it really has cleared some of this up for me. Now, I have a different question on semantics. I call them "Types" simply because... Well, that's what the documentation refers to them as, the keyword for them is Type, and calling them "Objects" rather gets me messed up by blurring the line between Blitz and a properly object-oriented language. What actually makes them Objects, then? |
| ||
| Well the reason not to call them "Types" is mainly that the word "Type" is then doing triple-duty, referring to the variable type (i.e. the system used by the compiler to know what the language should let you do with that value), the data structure/layout (what the field offsets actually point at and how many there are), and the thing itself. The first two have a 1:1 relationship in B3D, so we can ignore that confusion as it's never a problem (I mention it for completeness: using the same word here makes sense). But the third is clearly a different thing: it's a runtime construct, a block of memory, a "thing"; whereas the former is/are purely conceptual attributes (one an attribute of the variable, one an attribute of the data) that only exist at compile-time (... to add insult to injury, the runtime "thing" doesn't even have a metadata tag to tell the memory manager what its language-Type is!). "Type" as a keyword refers strictly to the first of these. The keyword is used to define structure only. ...the negative out of the way, I mainly call them "Objects" because 1. The "Object" command returns one; and 2. most of the other good words are taken (e.g. you might call them entities, but that would get confusing in a different way really quickly!). You could accurately call them "Instances of Type X", but that's long-winded. "Object" itself doesn't have a strict canonical definition the way some terms do (contrast type-theory, which is a decades-old branch of mathematics), at least not one everyone agrees upon. "Dynamically-allocated memory chunk" is generally understood to be the meaning of "object" in a non-OOP language, and it works consistently in that respect. So in conclusion, you don't have to call them Objects if you don't want to, but I strongly recommend for the sake of clarity that you ignore the docs' precedent and don't call them Types. (The docs are also written by a third party... so don't feel too bad about it.) |
| ||
| Out of curiousity...aren't blitz "types" really just very similar to C "structs" - so why not call them "Structs"? |
| ||
| Y'know, now that I think about it, that makes even more sense; even a strict OO language like Java refers to them as "classes" when defined, and "objects" when sitting in memory as created instances. I'd forgotten that detail. |
| ||
| even a strict OO language like Java refers to them as "classes" when defined, and "objects" when sitting in memory as created instances Now listen up: this is where it gets hilarious. In Java (and Smalltalk, which provides the inspiration for it, and other Smalltalk-derived languages like Objective-C), classes are objects too, because all classes are instances of the "Class" meta-class. This provides reflective ability by letting you send messages to a Class object to query the names and numbers of its methods and fields and so on. Meanwhile, over in the land of prototype-based OOP (Self, CLOS, JavaScript, ...Ravioli), there are no classes at all: objects are instantiated by creating runtime copies of other objects already loaded in memory. You can usually directly manipulate the fields and methods of objects in these languages and have them add and remove them dynamically. Class-based programmers usually tend to define "pseudo-class" objects whose main role is to be cloned, to fake "new". Are we all suitably confused yet? (I think I've now undone any clarification from earlier...) |
| ||
| Well, the first part does make sense to me; a class is a kind of "off-limits" object that all others are copies of, much like loading a bullet into Blitz3D with LoadMesh(), and then using CopyEntity() for every single instance that is to be used and rendered, keeping the base mesh out of sight. The second part lost me a bit though. You say objects are runtime copies of other objects already in memory... What put those in there in the first place? Am I confusing "runtime" with "build-time" or something? Where did the "already loaded" objects come from, and what defines their parameters and contents? |
| ||
| There is a much easier way of doing unlimited child types of a type with the ability to reference and iterate through a specific group while using the underlying blitz coding to handle the slower house keeping at a much faster speed than native blitz code can. However its a bit complicated to explain (and its getting late here) will try to find a post I made on the subject awhile back but I've improved on the system since. EDIT: Infact it was a thread you started originally awhile back: http://www.blitzbasic.com/Community/posts.php?topic=94874#1090390 See my post #6 tho I've improved on the system since and when I get time/my head around it again will explain it in more detail. Last edited 2012 |
| ||
| What put those in there in the first place? Well you have to assume that there is some low-level way to say "new object", but if "generic field-less object" is the only kind of object you can create, then that's effectively the same as having no classes (the difference is an implementation detail). Rather than do that (create an empty object an manually add fields to it), most prototype-based languages provide a built-in syntax construct for "make a new object with the following properties", e.g. in JavaScript you can do this: var vector3 = { x: 5, y: 10, z: 15 };... which will create an object with fields x, y and z and put it in the variable "vector3", and continue to create new objects every time that code is run. Cloning that object, with the clone method supplied by the generic empty starting object, might be one way to produce more 3D vectors; or you could compose that object with another one holding pitch yaw and roll to produce a six-fielded "transform" object. ...yeah prototype-based OOP is actually pretty different from class-based (one thing is that field accesses can't be precompiled down to simple pointer+offset, because there's often no guarantee a given object will actually support the desired field, plus the "composability" of multiple objects into one means that a field of the same name may not necessarily be found at the same memory offset). By this point we're talking about stuff that has absolutely nothing to do with idiomatic Blitz3D programming any more, so... don't try to apply this to learn more about Type management (this is just for the sake of interest and comparison). Last edited 2012 |
| ||
| By this point we're talking about stuff that has absolutely nothing to do with idiomatic Blitz3D programming any more, so... don't try to apply this to learn more about Type management (this is just for the sake of interest and comparison). I would never at any point this year claim to be a "Blitz3D programmer." I am a programmer, and sooner or later all horizons must be broadened.Anyway, I think I understand the concepts of prototype OOP now, although like any language I'd have to try it out in-depth for myself to fully understand the implications of it in practical terms. So many languages, so few clock cycles, eh? Thanks! |
| ||
| This is perhaps the most useful thread I've ever seen :D I should clarify - I'm not being sarcastic. I remember before I'd encountered OOP programming, I remember speaking with a friend of mine who had ONLY ever programmed in OOP - There was practically no common ground in linguistic terms for us to use without examples! Incidentally... ...yeah prototype-based OOP is actually pretty different from class-based (one thing is that field accesses can't be precompiled down to simple pointer+offset, because there's often no guarantee a given object will actually support the desired field, plus the "composability" of multiple objects into one means that a field of the same name may not necessarily be found at the same memory offset). Just as an aside, can you (if it's really feaasible to do so) explain what you mean by Prototype-based and Class-Based? The C++ I've been learning and instruction has shown to use Prototypes AND Classes, where often the Prototypes themselves will mostly be Virtuals for overriding. Last edited 2012 |
   |