Locked: The Art of Code: Namespaces and Inheritance

ID:287671
 
Feb 10 2012, 3:16 pm (Edited on Mar 24 2012, 1:25 am)


Nope.
#1 Feb 11 2012, 1:00 am
Good job, nice article.
#2 Feb 11 2012, 7:02 am
The inheritance example is pretty big. I understand inheritance but I'm not sure what I should be looking at there. It might be better to have a single, concise example (ex: just one proc) and relate it more to game development (ex: make it about attacking, or something people will use in games).
#3 Feb 11 2012, 3:02 pm
Yeah, that's a good point. I wrote some of the tutorial at about 4:30 AM and I was tired and... not in the best of judgement. I'll change it a bit.
#4 Feb 11 2012, 9:49 pm
Hah, how about that! Never realized you could use parent_type in THAT way. Thanks! :)
#5 Feb 12 2012, 5:15 am
Many people are hesitant to use parent_type or are even actively against it, but there's no reason that you have to use area, turf, obj, and mob as the only base atom types. If your game has items, make a type called "item" and set its parent type to "/obj". Many people would just deal with referring to items with types like /obj/item/weapon/sword when they could easily simplify things and make it /weapon/sword instead.
#6 Feb 12 2012, 5:34 am
Popisfizzy, keep up the good work. Both of your tutorials have been a good read, the first one gave a different approach to locations and its good to have those kind of thoughts available. As for this name space never thought to use parent_type like this, thanks!
It will be useful for organisation.
Keep up the good tutorials they help people in various ways even if its just a different approach which can lead to more doorways, thank you!
Know your effort is appreciated even if it isn't said :).
#7 Feb 12 2012, 1:23 pm
Falacy wrote:
You do realize that still uses obj as your base type?

I guess we should get rid of /area, /turf, /mob, and /obj. Since all they are is /atom/area, /atom/turf, /atom/movable/mob, and /atom/movable/obj. Then we can have type paths that look like /atom/movable/mob/goblin/kingGoblin, and we have to type out huge redundant type paths every time we want to refer to something.

Unless you can think of a reason why we shouldn't do this.

(edit: Though ultimately it should be /datum/atom/movable/mob)
#8 Feb 12 2012, 1:24 pm
Falacy wrote:
Well that wasn't long at all. When your code has more comments than actual code; you're doing it wrong.

I can agree with this to a certain extent. The "principle" behind commenting is to only comment when it's necessary, or to comment(if you're distributing a library) so that a developer can understand how a program works. I certainly don't see that in this article; Fizz practically hit all the main points. Sure, commenting on functions for this certainly isn't necessary, since it is obvious.
Drink() // It drinks when it eats.
        ..()


As for your definition of "bad examples", whether you like it or not, that's how inheritance works. My simple guess here is that you've never been exposed to or used an OO programming-language.
#9 Feb 12 2012, 1:28 pm
Falacy wrote:
Well that wasn't long at all. When your code has more comments than actual code; you're doing it wrong.

That was intentional. The idea is simple to get across, and thus doesn't need a lot of code. It needs more comments to clarify what is going on and the logic behind it than what it needs actual code. For future reference, there is no ideal, constant comment-to-code ratio. A piece of code needs as many comments as is necessary for the context it is being used in. In a tutorial, this is a lot.

There is so much unrelated and/or superfluous information, bad examples

Where? Please point it out piece-by-piece so I can shoot it down.

and the fact that this isn't even a good design concept in DM to begin with

Namespaces are useful in every object-oriented language, and they are present in a good god damned many. They are as useful in DM as they are in C++ or Java. Yes, they require an awkward syntax compared to other languages, but they are nonetheless present and intended to be used that way (or else parent_type would not be writeable).

I know it tweaks your nipples that you don't understand the use of namespaces, but they are useful nonetheless.

You do realize that still uses obj as your base atom type?

He clearly does, because that's how inheritance works. I'm pretty sure Forum_account understands this more than you do.

Because referring to it as an item and object gets the point across that it is indeed an item and object, not just some magical weapon type that you have to assume is inheriting who knows what from who knows where.

It is unnecessary to know that a /weapon is an /obj, just like it's not useful to know if a particular implementation of a stack or queue is inherited from a deque or is used as a wrapper around a deque. One of the basic principles of object-oriented programming is that it is not necessary to understand how a class works internally to use it, so long as you can use its interface. This includes what it is inherited from.

One of your biggest problems with all this is that you've never used a 'more typical' object-oriented language, where namespaces and inheritance work far more differently. DM is the only languages I know of, quite possibly the only language in existence, where the normal method of inheritance gives you information about what a subclass' superclass is. Hell, most languages have no way of doing it except possibly by assigning a subclass to a variable declared as a superclass, and that's wonky and very error-prone. You just have had the training wheels, along with a lot of other people, and now that someone has suggested removing them for someone else you're flipping out that that's not allowed.
#10 Feb 12 2012, 3:02 pm
I don't know about you, Falacy, but this certainly emphasizes more "code-readability" than what your standard approach is; everything is organized, and you can easily see where the inheritance is occurring.

Grenade
    parent_type =   /obj
    
    var
        maximum_dmg     //  The maximum damage at the center of a explosion.
        minimum_dmg     //  The minimum damage at the end of a explosion.
        radius          //  The radius of the explosion.
    
    //  Let's define the type of grenade here.
    M67 
        //  Assign all the properties for the M67 grenade-type we inherited from the Grenade.
        maximum_dmg =   25    
        minimum_dmg =   17
        radius      =   7
        
Gun
    parent_type =   /obj
    
    var
        damage          //  How much damage the weapon inflicts.
        spread          //  Functionality for spreading bullets.
        speed           //  How fast the gun shoots bullets. (i.e, fire time)
        
    MP5
        damage  =   1.4
        spread  =   1.5
        speed   =   0.20