View Issue Details

IDProjectCategoryView StatusLast Update
0000166LDMudLPC Compiler/Preprocessorpublic2009-10-05 12:49
ReporterlarsAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0000166: Add args to load_object() et al
DescriptionShort: Add. args to load_object(), clone_object(), allocate()
From: Alfe
Date: Wed, 16 Dec 1998 21:11:51 +0100 (MET)
Type: Feature
State: Acknowledged

ah, another thing: i'd like an optional second argument to allocate(),
which should be the value to initially fill the array with. e.g.:
allocate(5,3.1) ==> ({ 3.1, 3.1, 3.1, 3.1, 3.1 }).

Implement something similar for clone_object() and (new) load_object(),
with the additional args passed to create().
TagsNo tags attached.
External Data (URL)

Activities

zesstra

2009-09-27 18:39

administrator   ~0001319

allocate() is already solved, so there is the issue about
load_object/clone_object(). Sounds not like a bad idea to me... On the other hand you can get nearly the same result by
ob = clone_object(bar);
ob->initialize(foo);

alfe

2009-10-05 09:24

reporter   ~0001454

Last edited: 2009-10-05 09:26

Hi Zesstra,

Sure, ob->initialize(foo) can be used as a workaround for the missing "parametrizability" of the constructor facility, but it has obvious drawbacks; e. g. you will have to ensure that initialize() is called exactly once before the object is used otherwise. And you cannot really prevent "using" an object if the usage is done by just putting it into a container, passing it to a library function or similar.

Mudlib programmers can, however, use a simul_efun which clones/creates and initializes objects and forbid the use of the efuns clone_object() and load_object().

It still is an open question what loading by calling ("/foo/bar"->bla()) should do in these cases, whether it can be prevented and the like.

alfe

2009-10-05 09:28

reporter   ~0001455

btw -- that issue is so old i didn't even remember reporting the issue :-}

zesstra

2009-10-05 09:41

administrator   ~0001456

I see your point. But you have to ensure the proper initialization also if you do it via create() in load_object()/clone_object(). And you can prevent moving an uninitialized object if you really want to (not the case that an object is passed around as argument, but sooner or later somebody will do something more with it).
I am not so happy with making load_object/clone_object/create varargs and accept arbitrary arguments however.

alfe

2009-10-05 11:08

reporter   ~0001460

Last edited: 2009-10-05 11:09

I wasn't talking about moving it (in a mud sense) which you can prevent (but then the prevent_move() lfun needs to take care of this special case as well). Actually, I was just talking about putting it into a container like a mapping or an array.

Hard to find bugs are the reason why all other object-oriented languages (at least the ones I know like C++, Python, Java, Smalltalk, ...) allow creation also with parameters.

Anyway, what are the reasons against my proposal (besides being something utterly new in the 20-year-old LPC history which I followed nearly from its beginning)? I see no reason not to simply allow additional arguments. If the mudlib does not want to use it, so be it :-}

fufu

2009-10-05 12:33

manager   ~0001466

MudOS has such functionality since 1995 - it calls create() with any extra arguments passed to clone_object(). Note that this is a bit simpler in MudOS' case because there are no create hooks.

I'm not opposed to adding this feature to ldmud, although I believe that it's of limited utility.

I think that the implicit object creation by call_other() is a good reason against extending the feature to load_object().

bubbs

2009-10-05 12:49

reporter   ~0001467

Please add another vote in favour. If available, this would allow a cleverly designed core object to be instantiated very simply;

e.g. object sword = clone_object(WEAPON, "iron shortsword");

Could pass the additional params to the hook, which could ignore them or pass them to the "create" function as appropriate. i.e. unless the mudlib tweaked the hooks, no changes would be evident.

Issue History

Date Modified Username Field Change
2004-11-26 22:04 lars New Issue
2009-09-27 18:39 zesstra Note Added: 0001319
2009-10-05 09:24 alfe Note Added: 0001454
2009-10-05 09:26 alfe Note Edited: 0001454
2009-10-05 09:28 alfe Note Added: 0001455
2009-10-05 09:41 zesstra Note Added: 0001456
2009-10-05 11:08 alfe Note Added: 0001460
2009-10-05 11:09 alfe Note Edited: 0001460
2009-10-05 12:33 fufu Note Added: 0001466
2009-10-05 12:49 bubbs Note Added: 0001467