Language request
BlitzMax Forums/BlitzMax Programming/Language request
| ||
| @Mark Sibly: I can get around this in other ways, but (how can I phrase this?) how about making the Type, 'typed' ... ie. invent a new base datatype (essentially an int) called Class (say) and expose the typename as a Class type. Then extend Object to include a Class() function which returns the object's Class. to make this clearer I can now do this :- Type MyType EndType Local t:MyType = new MyType Local s:MyType = new MyType If t.Class() = MyType ' I'm a MyType , great! EndIf If s.Class() = t.Class() ' Me too! EndIf Oh, and we should also be able to cast a Class to Byte Ptr ;) Since I can then also dig around in the class (should I want to). Obviously the names are just semantic What do you say? It's a nice way of runtime type checking. |
| ||
| You could do: if MyType(t) ' Wee... endif |
| ||
| That isn't sufficient deps. That cast can be performed on anything extending from MyType (which isn't the real test being performed). The real test is to find out EXACTLY what type the object is.. not what it derives from. |
| ||
| In semantic terms it's probably a better idea to use the existing 'Type' keyword (since a type descriptor is already of type 'Type' - confused yet?). ie. in this case Type mytype EndType mytype is a Type then extend the Type keyword in the language parser for an object so :- Local s:mytype = New mytype If Type(s) = mytype ' That's a nice new language feature - thanks Mark! EndIf |
| ||
| The only thing we need is a method on BBObject class which returns the type it is as BM internally knows its type (otherwise you couldn't cast). There is already a function which does that but as it missuses Byte Ptr hacks to get it, I wouldn't use them if you plan to stay up to date, so I agree with this request at least partially. It would be great to have a method that returns us the class of a given type instance. |
| ||
| There are three reasons why I want this :- 1) It's missing from the language 2) To avoid using class hacks to make my code future proof. 3) To avoid instancing an object in order to test another's class. BM *does* know (for example) mytype is a Type - however there is no way to cast this to anything - nor can you even check two types are equivalent - ie, you can't do :- If mytype = yourtype etc... The compiler complains that 'Type' and 'Type' are unrelated. So we need everything I've asked for. |
| ||
| - and I do believe that a cast to a Type is a better option than a function which returns the type. What I mean is :- Type( myTypeInstance ) seems better to me than :- myTypeInstance.Type() (and as long as I can cast a Type to a Byte Ptr, I'll be happy : Dreamora feel free to express shock that I might wish to hack around the class) |
| ||
| I don't want to join any language theory debates, but this request sounds useful to me. Would be a nice to have feature. Edit: Brendane, did you see this ? My problem with this is that I'm unsure if this will work with future BMax-versions. So building functionality upon this is a bit jeopardy, I think. |
| ||
| I first thought, the target of your request is, to come away from the hundred casting behavior BM currently enforces. But after reading your example, it looks more like you want the === operator from PHP. But what I don't see is the reason why you should be able to do something like this between 2 types (ie 2 classes). type is a theoretic construct that does not exist at runtime. At runtime, objects exist so what you need is a check on instance base or on instance against class base but definitely not between classes as you already know that they are equal or not as they only exist in source code. so it is already defined if they are equal so its nonsense to test it. But there is a good reason to have a .class() command: currently you have to cast object through all potential types. While this is nice, it is extremely slow and not modular as casting can only be done at codetime. With a .class() method you could easily select it or check it against a dynamic array of typenames (either int or string, depending on the return of .class() ), which defacto means: dynamic class checking. This is currently not possible with the "out of the Box BM" I'm aware as well that you can easily work around that and I even do it. I've my own type TObject which is my base class I inherit from which has a field class which I use for such technics as they are needed in many cases. But I think this shows the restriction: It can only be done on your own types. BMs own types won't work ... |
| ||
| I agree with Brendane, except for one thing. Why would Marks Solution be better than doing it your self. I dont get it. I can add this funtionality to any class that I want to? Why should I be forced to carry this overhead on all classes simply because you are too lazy to impliment it your self? Its a nice thing, but I only need it on classes that are going to be cast. And as I know what they are, I should implement it myself I can get around this in other ways Yep better more suted ones (I know the overhead is low, but it is still an overhead) |
| ||
| @H&K: How can you have a better way than something built into the compiler? Also -what overhead are you talking about *exactly* ? There should be zero overhead involved in what I'm suggesting - except in the compiler. "Yep better more suted ones" - Please suggest a more suited method - I'm all ears. |
| ||
| How can you have a better way than something built into the compiler? If MyType.GFType = ThisObject.GFTypeIts a comparison of two Int? What major problem is there? (The overhead as I said was very small (Well ok an Int per type, but its still an overhead) |
| ||
| @Dreamora: It isn't my intention to compare 2 'classes'. My example was merely to prove that the compiler does not currently fully recognise that 'Type' is a type.. ie, I can't perform comparisons. Of course I shall be comparing an instance's type and an actual type. |
| ||
| @H&K: There are two problems in your suggestion that you tried to argue against a) there is an overhead involved - in my suggestion there isn't. b) it requires that I have created the type myself. What is the real point of opposing something useful like this? |
| ||
| What is the real point of opposing something useful like this? I am playing devils advocate.http://www.blitzbasic.com/Community/posts.php?topic=60015#669441 it requires that I have created the type myself. No it requires that you have at the least extended the type yourself |
| ||
| "No it requires that you have at the least extended the type yourself" So, I must extend every type myself? Then the type will no longer *be* it's original type - or have you missed the point? |
| ||
| So, I must extend every type myself? Yes. Well every type you might need to cast to and from No I havent missed the point. Im telling you that if you want this, then it has to be in your types, because I dont want this One int per type overhead arbitaray added to all the base types, simply because you dont know how to extend properly. (Remember I am playing devils advocate.) |
| ||
| @H&K: I am a professional c++ lead programmer. I know how to extend properly. If you're going to play devils advocate at least read the posts you're opposing. I've already told you, there is NO overhead required. Every object already has a class member - it is this value which is the Type. *Literally*. There is nothing but a change in the compiler that is required for what I'm after - the result will be that anyone can compare object types without pointless overhead or hacking the underlying object structure. No old code is broken in the process. It's all good, trust me. |
| ||
| I think Im doing quite well as devils advocate, no one thinks Im right, And you have been able to reitterate your point. |
| ||
| Hehe ;) I suspect Mark won't want to go tinkering unneccesarily with the compiler though. How about it Mark? It's my birthday soon. |
| ||
| @Jake.L : "Edit: Brendane, did you see this ?" Yes, thanks. I've also hacked around extensively with the class. In fact it's how I do it at the moment. You're right though, it's not a great idea to base important code on presumed structures which aren't fixed. However, I can be pretty much certain that the class member of the bbObject will never move or be changed, there is too much module code based on it for that to be practical. |
   |