ID:151624
 Dec 4 2009, 5:13 am
|
|
I've always wondered what was the difference between using obj or datum when handling skills?
| |
Datums hold information etc. Objs hold information and are drawn on screen, can be placed on the map, etc.
| |
Lundex wrote:
I've always wondered what was the difference between using obj or datum when handling skills? To clarify and expound a bit more on the answers already supplied... Metamorphman wrote: <code>/obj</code> is a sub-class of <code>/atom/movable</code> which itself is a sub-class of <code>/atom</code> which is in turn a subclass of <code>datum</code>. As mentioned, datums will only have the absolute most basic variables and procs defined for them, which is excellent if you are only using the datum as a place to store data for your skills. Jeff8500 wrote: Datums hold information etc. Objects hold information and are drawn on screen, can be placed on the map, etc. Datums cannot however, be drawn on the map. If you are using an interface list that populates from a list of datums and uses text, then datums are the way to go. If you are using an on client.screen HUD with buttons you would be clicking on, then objs are probably a wiser choice. (I personally would go so far as to use atom/movable's there, but the difference is negligible if you aren't making many vars/procs in /obj without subpaths) | |
I don't think there's any actual difference between atom/movables and objs, except that atom/movables aren't really intended to have any direct descendants besides obj and mob.
| |
Garthor wrote:
I don't think there's any actual difference between atom/movables and objs, except that atom/movables aren't really intended to have any direct descendants besides obj and mob. There aren't any by default (that I know of), but as I noted many people will define variables and procs under /obj. | |
I think the overhang of using obj vs atom/movable is probably more than worth the convenience of not referring to something as an atom/movable.
In general, though, I've found myself addicted to using Datums. | |
Chessmaster_19 wrote:
I think the overhang of using obj vs atom/movable is probably more than worth the convenience of not referring to something as an atom/movable. Ballz You can then forever refer to it as Ballz/X or whatever instead of atom/movable/Ballz/X | |
http://www.byond.com/docs/ref/info.html#/atom/movable
"You should not create instances of /atom/movable but should use /obj and /mob for actual objects." | |
Garthor wrote:
http://www.byond.com/docs/ref/info.html#/atom/movable Is there any justification to support that statement? It is simply the *exact* same as an /obj without being able to be placed in the map editor. I'm not saying everyone should use them, but if someone asks if there is a problem with it I'm definitely going to answer no. | |
That justification is what the reference says. The reference is 10/3 Jesus, so therefore you must obey it's word or burn in a pit.
| |
Jeff8500 wrote:
That justification is what the reference says. The reference is 10/3 Jesus, so therefore you must obey it's word or burn in a pit. The reference has and will always be wrong at times. There is no reason why you can't think for yourself sometimes. Point: Just because something wasn't created to be used for more than one specific purpose doesn't mean it CAN'T be used for more than one purpose. I'd give some examples like the harry potter brooms, but this is supposed to be a child appropriate forum. (If anyone remembers that news story, I will lol.) | |
It pretty expressly states not to do it, and it's a pretty general statement. Unless Dan was drunk when he wrote it, it probably isn't wrong.
| |
Jeff8500 wrote:
It pretty expressly states not to do it, and it's a pretty general statement. Unless Dan was drunk when he wrote it, it probably isn't wrong. It does, and the reason it provides is 'the only reason we put this here was so you could modify it.' So why would it be OK to modify procs/crease new procs but not define types? Matter of opinion IMO | |
Not really. The fact that they said it was only made a common ancestor for inheritance means that they never meant for it to actually be created, so it's unsafe doing so; it's the rough equivalent of using usr in a proc without knowing what you're doing.
| |
Jeff8500 wrote:
Not really. The fact that they said it was only made a common ancestor for inheritance means that they never meant for it to actually be created, so it's unsafe doing so; it's the rough equivalent of using usr in a proc without knowing what you're doing. Apparently my previous post disappeared. Quick summary: All you're saying is 'it wasn't meant for that purpose which means it is dangerous to use it for any other purpose'. And your analogy is completely flawed. If you can provide any viable reason for why it is mechanically or functionally wrong, or inefficient, or really any ACTUAL reason for why to not use it, then I'd really love to hear it. But just saying 'dey sed don't do it so itz wrong' over and over again isn't proving anything. I can provide many cases where you can use them with NO negative repercussions, can you supply any actual examples where it would cause damage? | |
In the future, the behavior of using an /atom/movable when you were supposed to be using an obj could change without warning. This leaves you with potential problems later on when there was no sense in ignoring the reference in the first place.
| |
They expressly said not to use it for that purpose, and so therefore they must have a proper meaning. It could be something as simple as an organizational thing (ex. the cocos2D-iPhone library has a class called CCScene that is the same thing as the CCNode class. However, the developer says use CCScene, obviously for some organizational, as well as some small inheritance related, reasons).
| |
Nickr5 wrote:
In the future, the behavior of using an /atom/movable when you were supposed to be using an obj could change without warning. This leaves you with potential problems later on when there was no sense in ignoring the reference in the first place. Sigh. You could use that exact same reason for not using anything. Ever. AJX wrote: If you can provide any viable reason for why it is mechanically or functionally wrong, or inefficient, or really any ACTUAL reason for why to not use it, then I'd really love to hear it. But just saying 'dey sed don't do it so itz wrong' over and over again isn't proving anything. | |
Jeff8500 wrote:
They expressly said not to use it for that purpose, and so therefore they must have a proper meaning. It could be something as simple as an organizational thing (ex. the cocos2D-iPhone library has a class called CCScene that is the same thing as the CCNode class. However, the developer says use CCScene, obviously for some organizational, as well as some small inheritance related, reasons). AJX wrote: If you can provide any viable reason for why it is mechanically or functionally wrong, or inefficient, or really any ACTUAL reason for why to not use it, then I'd really love to hear it. But just saying 'dey sed don't do it so itz wrong' over and over again isn't proving anything. | |
The difference between using objs and datums for differnt tasks is that you get a wide array of built-in procs to work with when using objs, whereas with datums you have very simple and necessary procs, so you can basically declare a new thing with the properties you want without the extra, un-needed properties of obj.