Can I add a method to Int
BlitzMax Forums/BlitzMax Programming/Can I add a method to Int
| ||
I want to do this. what can I do?local x:int ... x.keepin(0,800) 'keep it in the screen method keepin(low,high) |
| ||
| No. |
| ||
| Yes, i want to be able to do this aswell. Not this specific example, but extend classes over multiple files, multiple languages even. It would be possible if I could find the code for variable classes, but as far as I can tell there are none. |
| ||
| 'Variables' are not classes. They are simple datatypes. If you want to extend them, you'll have to write specific wrapper classes for them (like Java has). Example: Type TInteger Field myInteger:int <insert appropriate methods and functions here> End Type |
| ||
Type Screen_Coordinate Field x,y Method draw(x,y) If x>0 And x<800 And y>0 And y<800 drawstuff Return true else Return false End method End Type Global Screen:Screen_Coordinate = New Screen_Coordinate Screen.Draw(100,100) |
| ||
| ok thanks, I made it is there a way to pass by refrence without pointers? or is there any way so that I dont have to type varptr() every time? Function keepin(a:Float Ptr, lo:Float, hi:Float) If Var a<lo Then Var a=lo ElseIf Var a>hi Then Var a=hi EndIf EndFunction Local x:Float x=9999 keepin(Varptr(x),0,800) I might make my own float type because I also want to make x.keepin(min,max) x.wrap(min,max) x.moveto(target,speed) x.curveto(target,divide) |
| ||
| Flame - in a lot of modern languages the basic variable types are classes, and the advanced math operators are methods. I guess I presumed bmax would have this. Evidentyl not though. Yeah, functions are the way to do it, even though methods are more elegant. |
| ||
Function keepin(a:Float Var, lo:Float, hi:Float)
If a<lo
a=lo
Else If a>hi
a=hi
EndIf
EndFunction
Local x:Float=9999
keepin(x,0,800)
Print x
Tom |
| ||
| Bradford: Your Draw() method makes the method actually being a method rather useless. Better to remove x and y from the arguments of the method and use the fields of the class. |
| ||
| Yeah, functions are the way to do it, even though methods are more elegant. Get this man some Lisp, stat! :) |
| ||
| Variables' are not classes. They are simple datatypes. If you want to extend them, you'll have to write specific wrapper classes for them (like Java has). The same could be said of strings, yet they're clearly classes overloadeded with functions, as you can +- them and invoke built in methods. So it could be possible.. I'm having a hard time working out *how* bmax works though, it seems to me that it's relying a lot on C++ wrapppers/GCC to do it's internals stuff, which although it explains the lack of certain features, doesn't justify it.(If Road b is blocked, take another road, don't set up camp a hundred miles from home.) |
| ||
| But realize that a string is really a bunch of data behind the scenes: a length plus a pointer to a character array allocated elsewhere. An int is just a a raw 32-bit value. The original example of "x.keepin(0,800)" is a classic case where you don't want OOP. All you want is"x = keepin(x,0,800)" or "keepin(x,0,800)" depending on whether you want to pass x by reference or value. In other words, just a function, not an object. |
| ||
| The original example of "x.keepin(0,800)" is a classic case where you don't want OOP. All you want is"x = keepin(x,0,800)" or "keepin(x,0,800)" depending on whether you want to pass x by reference or value. In other words, just a function, not an object. You must not like the new addition x:+1 then? It is a member function that is the same thing as x.add(1) but with a symbol instead of "a d d". all you want is "x=x+1" or "x=add(x,1)" or "add(x,1)" depending on whether you want to pass by refrence or value. |
| ||
| Thanks Tom for the code. I couldnt find that in the docs |
| ||
| Ahh, but the distinction is that it tends to make more obvious sense that numbers know about adding with other numbers where are numbers knowing about range limiting, isn't. Also, some operators in C++ ARE NOT member functions they are just functions - not saying that this is the case for integers and the + operator, but just highlighting that they don't have to be member functions. Aaron |
| ||
| The same could be said of strings, yet they're clearly classes overloadeded with functions, as you can +- them and invoke built in methods. I could see it being possible to have Type suchandsuch Extends Int perhaps? |
| ||
What we can do in blitzmax is:player.gun.bullets = player.gun.bullets + 2 player.gun.bullets :+ 2 add player.gun.bullets,2 I would like to do this: player.gun.bullets.add 2 |
| ||
I would like to do this:player.gun.bullets += 2 But this is just fine: player.gun.bullets :+ 2 |
| ||
Coorae, surely you can do that!Type TPlayer Field gun:TGun Method New() Self.gun = New TGun EndMethod EndType Type TGun Field bullets:TBullets Method New() Self.bullets = New TBullets EndMethod Method Shoot() If Self.bullets.count()>0 Self.bullets.add -1 Return True EndIf Return False End Method EndType Type TBullets Field amount:Int Method Add(count:Int) Self.amount:+count EndMethod Method Count() Return Self.amount EndMethod EndType player:TPlayer = New TPlayer player.gun.bullets.add 2 Repeat Print "Players gun has "+player.gun.bullets.count()+" bullets left" If player.gun.shoot() Print " - KAPOW" Else Print " - CLICK - CLICK - CLICK" Exit EndIf Forever |
| ||
| Heh, innovative as ever. |
| ||
| The same could be said of strings, yet they're clearly classes overloadeded with functions, as you can +- them and invoke built in methods. No actually, the same could not be said of strings, because strings are not simple datatypes but are objects.You can tell, because it says so in the second line of the documentation everyone thinks is so awful. So it could be possible.. Except it couldn't. |
| ||
| There was something useful in the documentation? Holy hell, my world is crumbling around me... |
| ||
| No actually, the same could not be said of strings, because strings are not simple datatypes but are objects. Could Mikkel, Could. Not should. It could happen in plain english. (Semantics are nice, even when abused and misused) Anyway, My point was a string conceptually just a buffer of chars, yet he found a way to make them objects yet still expose them as regular string variables. (Which makes me think bmax has hidden operator overloaders :) ) not that I think ints should be or will ever be objects... |
| ||
| Anyway, My point was a string conceptually just a buffer of chars, yet he found a way to make them objects yet still expose them as regular string variables. That makes no sense at all. "Regular" variables do not have methods. More importantly "regular" variables that are actually an object cannot access methods.Thus I would argue a String is exposed as an object in BlitzMAX (since they work exactly the same way as objects, and not at all like "regular" variables). |
| ||
| (since they work exactly the same way as objects, and not at all like "regular" variables). Global Str1$ = "abcdef"
Global Str2$ = "abcdef"
Print ( Str1 = Str2 )
Type ASDF
Field x
End Type
Global Obj1:ASDF = New ASDF
Obj1.x = 5
Global Obj2:ASDF = New ASDF
Obj2.x = 5
Print ( Obj1 = Obj2 )
Print ( Str1 )
StrMutate( Str1 )
Print ( Str1 )
Print( Obj1.x )
ObjMutate( Obj1 )
Print( Obj1.x )
Function StrMutate( s$ )
s$ = s$ + "Blah"
End Function
Function ObjMutate( o:ASDF )
o.x = 10
End Function
|
| ||
| Ah, that's what he meant... |
| ||
| That makes no sense at all. "Regular" variables do not have methods. More importantly "regular" variables that are actually an object cannot access methods. It makes perfect sense. In theory, maybe the explination is lacking the mikkel level of googled encrusted authority, but still, a string allows you to do string 'concentration'(Subject to correct spelling.) Typically, in C++ to achieve this on a string class you'd use Operator overloading, and in effect write a function is called to perform the 'logic' of the operator. BlitzMax is obviously doing this for real on strings(Since as you say, they are objects) or is merely faking it(In the sense it's not an overloaded operator) If it's not faking it, i'd like the functionality exposed to us, so we can write our own. It's...useful. |
| ||
| Erm, the string class is exposed to modification, but it is in C. mod\brl.mod\blitz.mod\blitz_string.c I've edited it before but with not much luck since I'm more used to basic. After adding a function, you must also add a reference in the struct within the .c file, within the .h file, and within the blitz_classes.i file. BTW, there is really no way of saying how bmax thinks of its basic variable types. Presumably just data types since there are no fields/methods, but you never know. |
| ||
| there is really no way of saying how bmax thinks of its basic variable types. Sure there is. The compiler generates assembler code (the *.s files). An Int is a 32-bit value in memory, a Byte is an 8-bit value in memory. It treats the standard datatypes (with the exception of String) as a standard datatype. |
| ||
| Yeah, functions are the way to do it, even though methods are more elegant. Depends on your point of view. I find functions more elegant! OOP is useful, but you don't get any kind of win from making everthing and object, much as some people get all crazy about it. |
| ||
| The reason it is usually better is its easier to remember, and write code using the methods. For instance: Function Version SetEmitterSize(MyEmitter, width, height, depth) Method Version MyEmitter.SetSize(width, height, depth) At least, for me, the extra "emitter" in the function call is useless to include, but necessary so that other setsize functions may exist, for instance a particle one. Actually, in this situation the best solution would be a property, along with some odd syntax i've invented to pass multiple vars: MyEmitter.Size=width, height, depth This would call the set method of the size property. The get would have to be single parameter, because i cant think of any elegant multiple return syntax XD |
| ||
| At least, for me, the extra "emitter" in the function call is useless to include, but necessary so that other setsize functions may exist, for instance a particle one. Ah, but until you start to use overridden/virtual methods, there's absolutely no difference between the two. The method version is simply a function call, with the object passed in as a parameter. |
| ||
| I'm having a hard time working out *how* bmax works though, it seems to me that it's relying a lot on C++ wrapppers/GCC to do it's internals stuff, which although it explains the lack of certain features, doesn't justify it.(If Road b is blocked, take another road, don't set up camp a hundred miles from home.) C++ does low level stuff very well, and it also provides Mark with access to the C++ runtime libraries. |
| ||
| Ah, but until you start to use overridden/virtual methods, there's absolutely no difference between the two. The method version is simply a function call, with the object passed in as a parameter. Yes, you are right, functions and methods are for the most part the same. Except when it comes to syntactic beuty ;) See how much shorter, clearer the method version is?This is the most sensical way of writing it, because, the english language, and mathematics both use the structure of infix, where it is "Subject, Verb, Modifier", emitter SetSize sizevariables, 5/2. |
| ||
| Yes, you are right, functions and methods are for the most part the same. Except when it comes to syntactic beuty ;) See how much shorter, clearer the method version is? Well, syntactically I see very little difference. In one case you have a function name and four parameters. In the other case you have a method name and four parameters, except one of the parameters is in a different place! As a long-time professional programmer and game developer, I've tended to shy away from using OOP willy-nilly. Not because of paranoia or an unwillingness to change my ways, but because in a large program too much OOP tends to make things opaque. I know if I see a function call to ParticleSystem_SetEmitterSize exactly what it is. If I see s.SetEmitterSize, then I have to look at what s is first. That's why I see the function version as prettier. |
| ||
| Well, syntactically I see very little difference. In one case you have a function name and four parameters. In the other case you have a method name and four parameters, except one of the parameters is in a different place! alien_kill(alien,True) alien.kill(True) this applies to emitter |
| ||
| I see s.SetEmitterSize, then I have to look at what s is first. that would be bad. I would never have s be a particlesystem in one function and s be a ship in another function. I would have each type with a unique abbreviation. if s is used for ship, then particlesystem would have to use PS. if the program is huge there are way too many types, then there would be almost no abbrieviations. ship would have to be ship.x, and shotgun would be shotgun.x, and particleSys.setemittersize() |
| ||
| alien_kill(alien,True) alien.kill(True) The first line has two parameters: alien and True. The second line has two parameters: alien and True. They both do the same thing, just with different syntax. In the method case, a pointer to the object *has* to be passed around, otherwise you wouldn't know what object you were referring to. |
| ||
| Ya, so you See how much shorter, clearer the method version is? |
| ||
| Now suppose instead of "alien" someone has a local variable pointing to an alien object, but it's named "a" or "temp" or "attacker" or one of a million other things that might make sense in practice. So now you have: alien_kill(a, True) alien_kill(temp. True) alien_kill(attacker, True) vs. a.kill(True) temp.kill(True) attacker.kill(True) In the projects I've worked on, I've always preferred the former because it is very quick to see what's going on. This may be because I work on large, commercial games and not simply personal projects. In a long function that I didn't write, the last thing I want to see is "a.get_size()" or "temp.total()". |
| ||
| Depends on the environment. In the VB6 and beyond development environment all you need to do is put the cursor on the item you want to know and press shift-F2 and it will take you right to it. This handles the quick to see what is going on and makes it much easier to implement new types of things. But to each his own. |
| ||
| Now suppose instead of "alien" someone has a local variable pointing to an alien object, but it's named "a" or "temp" or "attacker" or one of a million other things that might make sense in practice. An interesting example, but it's a little too make believe isn't it? In any real world example, any given object (with multiple instances) will be part of some sort of collector, in which case a simple itteration will account for all of them. In a long function that I didn't write, the last thing I want to see is "a.get_size()" or "temp.total()". Why? Are you writting that large commercial game in NotePad? |
| ||
| This may be because I work on large, commercial games and not simply personal projects * bot builder creates a new file in protean, "Doom 3.bmx" * bot builder types Intro() * bot builder types Menu() * bot builder types End I work(note present tense) on large commercial games as well that aren't mere personal projects just to give my old fashioned opinion more weight. |
| ||
| I agree, this is too simplistic of an example to use to point out the limitations of OOP. In fact, I'd probably use OOP for this kind of coarse-grained classification, with each enemy type in an object, and those objects accept the same messages. In terms of larger scale, more complex uses of OOP and their associated problems, there are many good papers and discussions available. Here's an interesting one: http://www.paulgraham.com/noop.html |
| ||
| sorry if someone has already suggested this but i didnt read every post. Could you not do this because each variable extends Object inherintly so if you add methods to object type wouldnt they affect ints aswell? |
| ||
| Could you not do this because each variable extends Object inherintly so if you add methods to object type wouldnt they affect ints aswell? No.1) Int aren't Objects. 2) Polymorphism doesn't work upwards. Here's an interesting one: www.paulgraham.com/noop.html Yes. Very interesting. I stopped reading after the first paragraph where he calls everyone who doesn't agree with him stupid. I dunno, maybe he should just get out more... |
| ||
| FlameDuck: What else did you think to read from a LISPer that never saw anything like real OO ( Eiffel / C# and similar full OO languages ) |
| ||
| > Yes. Very interesting. I stopped reading after the first paragraph where he calls everyone who doesn't agree with him stupid. Then you missed him saying the same thing 5 times over, oh and also that large companies basically force programmers to use oop because they have lots of mediocre programmers. I liked that last bit the best. There was however no discussion of just why OOP was just a fad. |
| ||
| From the article: I personally have never needed object-oriented abstractions. No duh. OOP can be implemented in any procedural language as a preprocessor. You never need oop. I've done a lot of things (e.g. making hash tables full of closures) that would have required object-oriented techniques to do in wimpier languages, but I have never had to use CLOS. Nothing requieres oop. OOP is simply syntactic sugar (assuming you have types or structs). If not, it is still sort of syntactic sugar, except that you will have to do some stuff with arrays or membuffers to store data.Also, in the design article for "Arc" he says The great languages have been the ones that good programmers designed for their own use-- C, Smalltalk, Lisp. Erm, SmallTalk is as OOP as it gets. EVERYTHING is a class. seriously.And anyway, do you really trust a person writing an interpreter for a language that looks like this http://home.chello.no/~jthing/games/hangman.html |
   |