ID:1345979
 
One of BYOND's most powerful features is the ability to split proc calls indiscriminately between many different places. This allows you to organize code in very convenient structures - such as taking an entire *feature* and putting it into its own file.

movement.dm
calculate local density
move the player

cliffs.dm
..()
check if the target turf is a cliff
let the player leap down or climb up

swimming.dm
..()
check if the target turf is water
switch the player's graphics to swimming
slow their movement speed
reset them when they leave water

I'm racking my brain on different ways I could implement this into a C# application (preferrably single-threaded) such that I could use the same organizational methodologies that I've long enjoyed with BYOND.

Now, surprise to nobody, the C# community disdainfully abhores this methodology because there's no mechanism to specify the ORDER in which BYOND calls each proc/method fragment. However in my 12 years of developing on BYOND, I can count on one hand the number of times where the order actually mattered (fun fact: order is based on the order in which the files are compiled, generally alphabetical).

http://stackoverflow.com/questions/2088265/ c-sharp-partial-methods
http://stackoverflow.com/questions/13049403/ splitting-a-method-across-two-files-in-c-sharp


~Polatrite~
The problem more-so, I'd have thought, is a readability one. It's rather difficult to grasp what a method actually does, when it splattered over a number of locations.
In a more formal language, this really should be avoided and instead replaced with a proper hierarchical series of calls. If you need to do something like this, making more methods may be a better approach. Consider this in dm:

//global.dm
proc/setup()
..()
global.saves = read('savefile')

//load.dm
proc/setup()
..()
global.objects = read('object.xml')

//builder.dm
proc/setup()
..()
global.builders = read('last_builders.ini')


Clearly this is a contrived example, but it should demonstrate this point well enough. Consider instead making a function that is both more descriptive and less coupled to your other functions, such that it looks like this:

proc/setup()
setupBuilders()
loadSavefiles()
getOldObjects()

proc/setupBuilders()
global.builders = read('last_builders.ini')

proc/loadSavefiles()
global.saves = read('savefile')

proc/getOldObjects()
global.objects = read('object.xml')


This makes your code more decoupled and readable, because instead of having multiple non-descript methods, you now have methods that have descriptive enough names where you can deduce what they do.

If you really are opposed to this, my only other recommendation could be to use a hierarchical model that represents this. Here's some pseudocode:

class initializer
list modules = [ builders , saves , objects ]
for each module
load module

class module
new
call setup

class builders extends module
setup
global.builders = read('last_builders.ini')

class saves extends module
setup
global.saves = read('savefile')

class objects extends module
setup
global.objects = read('object.xml')


Keep your code readable!
In java, its called super()
In response to FIREking
That's not what he was asking. He was asking for partially implemented methods that call each sibling and the parent, not for inheritance to call the parent methods.