Object and Handle Commands
Blitz3D Forums/Blitz3D Programming/Object and Handle Commands
| ||
| What is up with the elusive Object and Handle commands?? they are listed in the B3D docs, but there is no help page for them. they are highlighted in the IDE and ive seen them used before, but i cannot find any more information on them and I beleive that they are the culprit in an "illegal type conversion" error that i keep getting. can anybody shed some light on these commands? |
| ||
Handle() retrieves the handle of a type instance, i.e.m.mytype = new mytype h = Handle(m) You can then retrieve that type for later use with the Object command m.mytype = Object.mytype(h) m\blah$ = "whatever" |
| ||
| Seems to be good for creating a direct reference from an entity to its container type in order to avoid iterating through the entire list of instances. |
| ||
| Primarily useful for polymorphism - when you want a field to be able to hold a pointer to more than one type of object. Of course it's up to you to keep track of what types of objects your handles are for. Handle() returns an integer, starting at 1 and incrementing for every handle created. Calling Handle() multiple times on the same object will always yield the same number. Object.type() returns null if given 0, a handle to an object which has been freed, or a handle to an object of a different type. |
| ||
| i see. this is fairly confusing considering that the value that Object() returns is also called a handle... so if i understand correctly, Handle() is used to "name" a certain object to to speak and Object() returns the handle of the object bearing that "name"...? I think i get it thanks everyone. btw, perhaps we can have some documentation on these commands in the next release of the BlitzDocs...along with BlitzArrays >_< |
| ||
| As far as I'm aware, the word on Object() and Handle() is that they're, well, "undocumented"... ie you're not supposed to use them because they could be dropped at any update. Since B3D development has slowed recently one could argue that the chances of them disappearing at this stage are slim though. |
| ||
| >they are listed in the B3D docs No they're not! > but there is no help page Because they are not listed. >for them. they are highlighted in the IDE Because they are undocumented commands. >and ive seen >them used before, but i cannot find any more information >on them Because they are undocumented! >btw, perhaps we can have some documentation on these >commands in the next release of the BlitzDocs...along with >BlitzArrays Don't expect that to happen. People have been asking for this since they were first discovered, but they are apparently 'undocumented' because they are for internal BRL testing purposes only and could be subject to change at any time. However, they have been in the language for eons, so maybe it is time to make them official. Andy |
| ||
| I see these functions as integral parts of the language. If they are removed in the future and not replaced with another feature which provides their functionality, I will not be upgrading. If they didn't exist in the first place, I would not have been very happy with my purchase. this is fairly confusing considering that the value that Object() returns is also called a handle It is? I calls it a pointer. |
| ||
| Until recently I didn't know how to use these, but as of a few months ago I use them all the time - they are quite useful commands as you don't have to cycle through entire instances of types if you know which one you wish to get to, assuming you've stored the 'handle' somewhere. Would be a shame to see them disappear, although I can't really see that happening. |
| ||
| this is fairly confusing considering that the value that Object() returns is also called a handle This has lead to some confusion. I think it would have been better if the Handle command was called HandleID, or something similar. |
| ||
| Objects/Handles Advance types definitive types |
| ||
| there is a reason why they are not documented.... |
| ||
| there is a reason why they are not documented.... I've always wondered. What *is* the official reason for them not being documented? |
| ||
| I was waiting for Frank to chime in. ;) Argh, responding to flame-bait is so hard to resist! |
| ||
| :) Yeah, im just pullin ya strings octo, there aint nothin wrong with object/handle commands, but a custom solution can work well too. BTW, I was interesting in using your Hash Table functions but I'm difficulty figuring out how i can implement them. |
| ||
| Show me what you're trying to store and I'll show you how to use them. :) |
| ||
| octo, I understand the basics of a hash table. Im ultimately using it in my Command Line Interface for rapid lookup. The CLI command string format is Verb-Object-SubObject-Property. The parser separates and tokenizes the words in the string and uses hashing for rapid comparison valid VOSP. I've written my own Hash functions but haven troubles with collisions. Const HASH_PRIME=383
Const HASH_MULTIPLIER=5 ;65599
Dim hash_Table.hashentry(HASH_PRIME)
Type hashentry
Field name$
Field blah$
End Type
Function hashIndexGet(hashstring$)
hashstringlength=Len(hashstring)
hashmultiplierexp=hashstringlength
While (hashoffset<hashstringlength)
hashoffset=hashoffset+1
hashmultiplierexp=hashmultiplierexp-1
hashfactor=hashfactor+(HASH_MULTIPLIER^hashmultiplierexp*Asc(Mid(hashstring,hashoffset)));
Wend
Return hashfactor Mod HASH_PRIME
End Function
Function hashentryNew.hashentry(hashentryname$)
this.hashentry=New hashentry
this\name$=hashentryname
hash_Table(hashIndexGet(this\name))=this
Return this
End Function
Function hashentryKeyGet.hashentry(hashentryname$)
Return hash_Table(hashIndexGet(hashentryname))
End Function
;create a new entry
hashentry.hashentry=hashentryNew("test")
;get object by using hash key
hashentry.hashentry=hashentryKeyGet("test") |
| ||
| To fix your hash: instead of having your hash buckets point directly to elements, point them each to their own linked lists of elements - that way collisions cost you performance instead of the loss of data integrity. This means that whenever you look up an entry, you need to walk the correct bucket's list and look for a matching key; if there are no collisions in your hash, there'll only be one element to check. To use Container: hash table instead (which takes care of all that for you:)
Include "hashC.bb"
Global verb_hash.hashC = hash_new()
Type verb
Field name$
Field blah$
End Type
Function verb_new.verb(name$)
v.verb = New verb
v\name = name$
hash_set(verb_hash, name$, Handle(v))
Return v
End Function
Function verb_get.verb(name$)
Return Object.verb( hash_get(verb_hash, name$) )
End Function
;create a new entry
verb.verb=verb_new("test")
;get object by using hash key
verb.verb=verb_get("test")
Note that I've renamed your type from "hashentry" to "verb" to prevent confusion. I don't understand enough about your requirements to know whether you need four separate hashes ("verbs", etc.) or one hash ("CLI words"). Either way, it's cake. :) |
| ||
| thanks, octo. There is a separate hash table for Verbs, Objects, etc. I'll work with this. |
| ||
| No problem, glad I could help. Wait... what? I converted you already? But you were my monomorphic nemisis! What am I going to do with all these exploding cigars?! |
| ||
| Perhaps, I converted you. lol. Thanx again! |
   |