ID:138103
 
Finally I can have all map objects inherit the same procs and vars! This will save much code duplication.

We'll have to deal with explaining a slightly more complicated situation, but removing code duplication (and the most common use of ':') will help all code everywhere.
Finally I can have all map objects inherit the same procs and vars! This will save much code duplication.

Oh, I just read the notes... that is neat!
On 4/1/01 11:32 pm Deadron wrote:
Finally I can have all map objects inherit the same procs and vars! This will save much code duplication.

We'll have to deal with explaining a slightly more complicated situation, but removing code duplication (and the most common use of ':') will help all code everywhere.

I'm iffy about it, myself. Since I rarely typecast anything for more than one object, the atom notation is fine by me, but that also means that all of my data objects (which I use a LOT of) will now have to be prefixed with /datum... which means an extra 6 bytes per type reference! =)

In response to Spuzzum
On 4/2/01 3:15 pm Spuzzum wrote:

I'm iffy about it, myself. Since I rarely typecast anything for more than one object, the atom notation is fine by me, but that also means that all of my data objects (which I use a LOT of) will now have to be prefixed with /datum

No they won't. /datum should be the implicit parent_type.
In response to Spuzzum
that also means that all of my data objects (which I use a LOT of) will now have to be prefixed with /datum... which means an extra 6 bytes per type reference! =)

I should emphasize that when you set parent_type, it does not effect the path of your object in the type tree. You could define all of your types at the top level, using parent_type to do all inheritance, and you would effectively have a system like C++ or many others in which all object types are in the same namespace.

The path to an object in the DM type tree is now somewhat independent of the inheritance of that object. An object defined at the top level with no specified parent_type implicitly inherits from /datum, but the path to your new object is still /MyType, not /datum/MyType.

I find the heirarchical DM type tree to be most elegant when you are writing a library or something and do not want to create a heavy impact on the global namespace. And sometimes there is an insignificant little type (such as /atom/movable) which really doesn't deserve its own top-level name because you would just have to name it something like /movable_atom in order to remember what exactly it is anyway.

On the other hand, there are times when strict heirarchy can be annoying. That's why we originally made the atomic objects at the top-level, because it seemed ugly to have the most basic types sunk several levels deep in abstract object types that most people wouldn't use.

This new parent_type feature gives you the ability to pick and choose between the two approaches. It certainly should not require you to change any code what-so-ever. In fact, I made this change partly because of your complaint about the recent change (which I retracted) that generated run-time warnings upon calling undefined procs. The reason you were calling undefined procs was legitimate, given the inability to conveniently share a proc definition between multiple top-level object types. Now it should be possible to avoid that, but I won't put the warning back in for a little while anyway, just to give everyone a chance to adjust. Try to be good from now on and define procs at the highest level of inheritance where they will be called.

--Dan
In response to Dan
This new parent_type feature gives you the ability to pick and choose between the two approaches. It certainly should not require you to change any code what-so-ever. In fact, I made this change partly because of your complaint about the recent change (which I retracted) that generated run-time warnings upon calling undefined procs.

I agree wholeheartedly with Tom that it would confuse newer users, who if they were getting copious '.' errors could just go on a global '.'->':' replace and, well, nothing would work again.

I think you should keep the error message and put in an option to disable it, personally. But it's still your call.

The reason you were calling undefined procs was legitimate, given the inability to conveniently share a proc definition between multiple top-level object types. Now it should be possible to avoid that, but I won't put the warning back in for a little while anyway, just to give everyone a chance to adjust.

The way the code worked was that I had tons of objects that used my electrical.dm file, which used a /obj/power_source item that has its Conduct() proc that attempts to call the Conduct() proc of all objects nearby. If the item doesn't have a Conduct() proc, then it obviously isn't electrical and nothing will happen.

See my reasoning here? It might seem like bad form, but it saved me from having to subclass all electrical objs of type /obj to /obj/electrical, which were fairly harshly interwoven and based off of those types (before I had my electrical code at all). And since I had drawn a lot of objects onto the map that used the old class, I would have to go through the bulky and unintuitive (sorry) Unable to Load Object Types interface, and type in manually /electrical into each object type that I needed to replace, as well as to go on a spurious code-editing spree.

Try to be good from now on and define procs at the highest level of inheritance where they will be called.

Well, if it's a feature of the language, I think I have every right to do it my way! If it works that way, then it works that way! =)

Ah, heck, Warrior's electrical stuff stopped working a while ago, and I need to overhaul that part anyway. You can put the error message back in if you please.
In response to Spuzzum
Ah, heck, Warrior's electrical stuff stopped working a while ago, and I need to overhaul that part anyway. You can put the error message back in if you please.

Personally I like the idea of having run-time warnings if you try to call a proc that doesn't exist. I had gotten so used to that being the behavior for vars that I just always assumed it applied to procs as well.

On the other hand, it'd be nice to be able to trap run-time warnings if desired. Something like this would probably suffice:

#define __ERROR_HANDLER__ /proc/HandleError()

//On runtime error, a predefined set of args is passed to error handler:

proc/HandleError(lastSrc, errorLine, list/stackTraceLines) //or whatever
world << "I... see... NOTHING!"
In response to Spuzzum

See my reasoning here? It might seem like bad form, but it saved me from having to subclass all electrical objs of type /obj to /obj/electrical

Yes. Under the new system, you could do this:

atom/proc/Conduct()


And then only your true conductors would actually define an action for Conduct().

My point is that the new system allows you to define new properties of atomic objects.