Just checking: Public/Private can't be used ...
BlitzMax Forums/BlitzMax Programming/Just checking: Public/Private can't be used ...
| ||
| in types for fields and methods (and functions) can they? This would be great to show which fields/methods are for internal and external use. I guess a naming convention should be used instead (or as well as). |
| ||
| It can't, unfortunately. |
| ||
| I guess a naming convention should be used instead (or as well as). Sure. Except the compiler won't enforce it, so it's ultimately pointless. |
| ||
| so it's ultimately pointless. Not really as when making types with a lot of fields and methods for other people (i.e. stuff in my framework), I could notify people that anything with and _ on the start is private and not to be used externally for example. However, it's probably way too late to do that for my framework as it would break lots of stuff, shame :-( |
| ||
| @Grey: Search&Replace could do the trick. However, this might break code on your users side. On the other side, private functions/fields shouln't be called so much from an app, right? You can use Private/Public only to hide functions/types, but like stated above only complete types, not a single function inside a type. I use it to hide helper functions (like Pow2Size and such) and OS API declarations. Jake |
| ||
| Good idea bout the helper functions. Yeah it's breaking it for my users I don't want to do, but you are right, they shouldn't be used much. Really I'd like to overhaul the whole thing with better naming conventions...and some more standardised stuff. Like a framework 2.0. |
| ||
| Private really ought to work properly to define visibility of functions, fields, etc in types. It doesn't seem *that* hard a change, but I guess there must be other priorities. BRL convention seems to be prefix with _ for now. |
| ||
| I could notify people that anything with and _ on the start is private and not to be used externally for example. Sure. But that doesn't prevent anyone from invoking it out-of-order accidentally. |
| ||
| correct. I'd rather we had proper Private/Public to be honest. |
| ||
| It would be a nice feature, but a shared coding style will still be needed as a DAU will always find ways to break anything you do ... so unless he/she knows what he/she is not meant to do, you can only count on the fact that you will get troubles. |
| ||
| I have a stupid question.. when people buy and use your framework, can they read its actual source code? |
| ||
| Yes. I want people to be able to see how it works and then they can either use it as it is, or copy it and modify it for their use or whatever really. People also contribute improvements and fixes which is great. |
| ||
| In that case, Sure. Except the compiler won't enforce it, so it's ultimately pointless. By not "advertising" the _fields in the documentation, the only way the users can discover them is by looking at the source code. And even if there were a fully-working public/private system there would be nothing to stop them from simply changing the field type. |
| ||
| yes, but the whole point of OO is to make things unbreakable. You can do any changes you want as long as you keep your public or static methods intact. Problem of course is that's it's not always so easy to understand what is public or private. So Jake, IMO it would be better to add the _style asap, better even in the 1.05. As the 1.05 is in still in beta you should take the chance ( and don't forget the documentation overhaul, too many docs and sources to search through to find pieces of information) |
| ||
| Yeah I know, but it could be a REAL bind changing the variable names. It's OK for new people but not for existing customers how may have referenced them...But it makes sense to overhall BEFORE I revamp all the docs...maybe I should do a survey to see if anyone strongly objects. |
| ||
| Yes this is true, for new customers it would be better to distinct public/private, the existing customers of course may want to kill you ;) .. but then again it's normally never a good idea to change a framework version in the middle of production, even 1.04 and 1.05 isn't totally compatible anymore. And the features that are new haven't probably been used a lot. So the existing customers have the choice of adding the new features they want to the 1.04 framework, or if they absolutely want the 1.05 they would need to be careful anyhow. At least that's my humble opinion :) |
| ||
| There's only a couple of minor changes in the way the framework is started in V1.04 and V1.05 (but they are for the best). The rest of it is 100% compatible. Changing var names could break lots. It's OK for you as you are new to it ;-) |
| ||
| :) I must admit I'm having a tough time with your framework but I guess a big part of it is due to my basic knowledge of BMax. Good that I have some Java knowledge though, so most of the OO stuff is quite familiar. OT: How did you create your maps for your games? Did you write your own mapeditor or what do you use or how do you design your map? |
| ||
| Sorry to hear you are having a tough time. Hopefully you've learnt a lot already though! For my match-3 games in Blitz Plus I wrote a map editor (same for Iron Fist). For my match-3 games in BlitzPlus, Indiepath wrote an editor and I modified it. For my current game, there was already an editor made in Java. For my framework demos the maps are randomly generated. |
| ||
| By not "advertising" the _fields in the documentation, the only way the users can discover them is by looking at the source code. Or by using an IDE that doesn't suck. And even if there were a fully-working public/private system there would be nothing to stop them from simply changing the field type. Sure. But I'm thinking people are going to reckon it's private for a reason, were as a leading underscore is completely ambiguous (and may obtain a double meaning if you're already using it for something else [like for instance globals, constants or enumerators]). |
| ||
| Just to make things clear, your framework is top notch! although the documentation could be enhanced a little bit, but you now that of course and are working on it. And not to speak of your fantastic support! I'm only a little (big) frustrated, because I have so little time working continuously and with BMax one has to create very much from scratch (thankfully less now due to your framework) Heck, I was even looking at GameMaker again and TBG. I really wonder why nobody has created a great (even commercial) map-editor for BMax. But these are all pore excuses, I should get more sleep again and this is getting too OT... |
| ||
| I really wonder why nobody has created a great (even commercial) map-editor for BMax. Just checking that you are aware of TileStudio, Mappy (+Pro version), FishEd, World Editor (with source), Scotts Map Editor 2 thing (with source). I think UME has a Bmax loader as well. |
| ||
| Barbapapa: Thanks! Yeah checkout the editors TonyG is mentioning. I plan to make some too in the future. Made plenty in the past... |
| ||
| There is a great mapeditor for BM: Mapeditor.de.vu Vertex ported the tile engine to BM so its simple :) |
| ||
| Yeah, thank you all. I tried World Artist, which doesn't seem bad but it is not supported anymore. I don't know why but the map ran very stottering, using the cpu in a very unbalanced form. I'll try the others too, but the main problem lies in myself, I have some really great ideas, too many, and writing a solid game document isn't the problem either, but then converting takes so much time that I lose patience. So you see, it's all my fault, must work at it, you know like some ancient japanese, being able to spend the whole life in creating one sword, maybe not so extreme ;) Gee this Topic has really turned ot, sorry Jake... |
| ||
| don't worry about it. Hey I just spent 8.5 months making a "sword" and it was tough going, esp. at the end with the crazy hours to hit a dealine. My suggestion is start with something very small, esp. if you are part time. Think about this, think you can make a simple game in 100 hours? Say you can only put in an average 10 hours a week, that's still 10 weeks = 2.5 months for a simple game. Once you start completing simple games, make bigger ones :-) Don't start big (I did with Iron Fish and got disheartened). |
| ||
| Thanks for your kind words. Normally I'm a very fast worker and a fast learner, I even created a crazy model of a modernized barn, plenty of renderings and did a huge walktrough for DAU's with B3D I used the first time ever, all around the birth of my smallest, sheesh, and now I feel braindead...maybe because I thought I could commence very fast, see at least some results, but I didn't think of tools I need to even be able to start. You know what, you are right, new language, new rules, must give me some time..... You'll here from me ;) (not meant as threat ^^) |
| ||
| Sorry to hijack again but you can download the Bmax source for World Artist and support yourself. :) |
| ||
| I have to jump in here and warn people about FishED. I purchased a copy and have heard nothing from the developer. No License key, No full version, Nothing. I've repeatedly emailed him but get no replies. AVOID FishED! |
| ||
| Hands up, you hijackers!! @tonyg: Yes indeed, the sources give a wonderful insight on how something like this is achieved. @Amon: Good to know, if you payed with a credit card you should be able to have your money refund. Good Luck! The Mapeditor Dreamora mentioned seems very nice too. Don't know if it's kept up to date though. |
| ||
| By the way, how do public and private actually work? I can use them in C-style but never got them working in Blitz. |
| ||
| ..and we're back on topic :) the key points are accessible or not accessible from outside the source. Was this your question? Public Description Public makes a Constant, Global variable or Function accessible from outside the current source file (Default) Example Rem Public makes a variable, function or method accessible from outside the current source file (default). End Rem Public Global Score,Lives,Health Private Global posx,posy,posz Private Description Private makes a Constant, Global variable or Function only accessible from within the current source file Example Rem Private makes a variable, function or method only accessible from within the current source file. End Rem Public Global Score,Lives,Health Private Global posx,posy,posz |
| ||
| Oh so Type bbiogjjdiojsfd private field jjfjmcvom public field lcxpgoj end type Is not the way to do it? |
| ||
| That doesn't work, but is what we want. Private doesn't work within types, but you can make one type private, the other public, and the same for functions, globals, etc. |
| ||
| Re: FishEd I had a number of issues with my ISP in September which led to some emails going astray; I thought I had managed to resolve all of the missing orders but yours must have slipped through the net. Your money has been refunded, and I apologize for the inconvenience. |
| ||
| I've found an interesting way to make a sort of private fields and methods in modules. Code for module blide.test1 (blitzmax/mod/blide.mod/test1.mod/test1.bmx) SuperStrict Import brl.max2d Type LineConcat Field _private:TLConcatPrivate = New TLConcatPrivate Method DrawLine(x:Int, y:Int) _private.DrawLine(Self, x, y) End Method Method SetPos(x:Int, y:Int) _private.X = x _private.Y = y End Method End Type Private Type TLConcatPrivate Field X:Int Field Y:Int Method DrawLine(LC:LineConcat, x:Int, y:Int) brl.max2d.DrawLine(x, y, Self.X, Self.Y) Self.X = x Self.Y = y End Method End Type Public Example file: SuperStrict
Import blide.test1
Graphics(800, 600)
Cls
Flip
Local P:LineConcat = New LineConcat
p.SetPos(Rand(0, 800), Rand(0, 600))
While Not KeyHit(KEY_ESCAPE)
p.DrawLine(Rand(0, 800), Rand(0, 600))
SetColor 0, 0, 0
DrawText("Using base class. (PRESS ESC)", 1, 1)
SetColor 255, 255, 255
DrawText("Using base class. (PRESS ESC)", 0, 0)
Flip()
Wend
Cls
Type LineConcatExtended Extends LineConcat
Method DrawLine(x:Int, y:Int)
SetColor(Rnd(0, 255), Rnd(0, 255), Rnd(0, 255))
Local F:Float = GetLineWidth()
SetLineWidth (7)
Super.DrawLine(x, y)
SetLineWidth(F)
End Method
End Type
Local p2:LineConcatExtended = New LineConcatExtended
While Not KeyHit(KEY_ESCAPE)
p2.DrawLine(Rand(0, 800), Rand(0, 600))
SetColor 0, 0, 0
DrawText("Using extended class. (PRESS ESC)", 1, 1)
SetColor 255, 255, 255
DrawText("Using extended class. (PRESS ESC)", 0, 0)
Flip()
WendIn this example, the data contained in the field _private can't be modified from the program using the module. If you try to do so, the program doesn't compile. And the best news is that this is not affecting inheritance or external usage of the module, so a little heretic solution. Not very elegant, but better than nothing. |
| ||
| Interesting solution! Would need a bit too much rewriting for me though. Roll on Private and Public fields/methods in BMax is what I say! |
| ||
| As I mentioned over there there is a simpler way: 1. Make sure the stuff you want to be private has a specific naming convention like _... 2. The stuff that shall be private must always be put after the stuff that is not private in the source (ie first public fields, methods, functions, then private field, methods functions...) etc 3. build the module 4. then go into the .i file and just remove the blocks with the _... in Its vital that the methods and fields are at the end other wise the pointers will tick out and you are having issues. I assume thats how the current implementation of private and public works as well. A simple rewrite of bmk to reorder the stuff and take that into account would have had allowed private since at least 1.18 as I am using it since then. I just never invested the time in modifying the BMK to do so as I never released kamaya any further than beta as the interest died down |
| ||
| 4. then go into the .i file and just remove the blocks with the _... in And given that's all there is to it, I really don't see why blitzmax couldn't be changed to do that itself fairly easily... |
| ||
| Dreamora: wow neat trick! |
| ||
| Neat trick, indeed. But if I understand it right you have to edit the .i file each time you compile the mod. I would stick to the "_<variable" naming convention. But maybe someone from NZ want's to camp in front of Mark's home until he does buildin private fields/methods ;) Jake PS: Puki, where you from? *eg* |
| ||
| Yupp you would have to unless you write a small little program that does this automatically. the _ convention is great but I think the idea here was to remove any possibility that a DAU can break it without breaking the module file itself :) You know murpheys law: "Anything that can go wrong, WILL go wrong" :) And assuming that DAU (dumbest assumable users) are an exception to that rule in the way of "no way it can not go wrong", its a good thing if you can prevent them from touching stuff they shouldn't. |
   |