View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000166 | LDMud | LPC Compiler/Preprocessor | public | 2004-11-26 21:04 | 2009-10-05 10:49 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000166: Add args to load_object() et al | ||||
| Description | Short: 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(). | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
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); |
|
|
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. |
|
|
btw -- that issue is so old i didn't even remember reporting the issue :-} |
|
|
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. |
|
|
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 :-} |
|
|
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(). |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 21:04 |
|
New Issue | |
| 2009-09-27 16:39 | zesstra | Note Added: 0001319 | |
| 2009-10-05 07:24 | alfe | Note Added: 0001454 | |
| 2009-10-05 07:26 | alfe | Note Edited: 0001454 | |
| 2009-10-05 07:28 | alfe | Note Added: 0001455 | |
| 2009-10-05 07:41 | zesstra | Note Added: 0001456 | |
| 2009-10-05 09:08 | alfe | Note Added: 0001460 | |
| 2009-10-05 09:09 | alfe | Note Edited: 0001460 | |
| 2009-10-05 10:33 | fufu | Note Added: 0001466 | |
| 2009-10-05 10:49 | bubbs | Note Added: 0001467 |
