ID:900646
 Jul 30 2012, 11:13 am (Edited on Jul 31 2012, 3:55 am)
|
|||||||
| |||||||
A flag of some kind, so it's easier to tell if the datums new procedure is being called by load. Error checking can be difficult, when you can't tell if the parameters are incorrectly null, or it's just being loaded. I know I can work around it, but the work-arounds I can think of are unpleasant.
| |||||||
If I'm understanding you correctly, you want to be able to tell when an object is being loaded from a savefile verses being freshly created in its New() process.
Here's the workarounds I can think of, hopefully one of them is more palatable than what you've thought of so far: A) Define an initialized variable on your objects, that is set to true when New() is originally called. B) Set a global variable LOADING_SAVEFILE whenever loading a savefile, and then unset it when done. You'll have to be careful to make sure it's always unset, even in the event of unexpected errors (common with savefiles). Because BYOND is single-threaded, you'll be able to check in New() if LOADING_SAVEFILE is true. It's ugly from a design standpoint, but effective and easy to implement. C) Use your own argument flag in New() to mark when it isn't being loaded from a savefile. As handy as this feature might be, I'm not sure how you could implement it without breaking backwards compatibility and introducing unexpected bugs into existing code. But I'm not a part of the staff, so maybe Lummox JR or Tom will have an idea on how to implement it. | |
DarkCampainger: You understood me perfectly
"A" would have to be done before new is called, which wouldn't work, because the object has to exist first. The "B" solution scares me, because the slightest delay() could screw up the whole thing, but it's a very good solution. The "C" solution would work great, but it would be hard to tell the difference between a messed up new, and a loaded new, on top of being tedious. I think an internal variable sort of like usr, but for loading, that gets passed to new would solve the problem. So sort of like "C" being done internally. It wouldn't break compatibility. Another solution is putting a new variable on datums, that is set to true before new is called when it is loading. I came up with a solution "D" and "E" "D" sleep in New, which makes the loader set all the variables, and then check the variables. This is prone to backfiring on things that need the object now. "E" Make a new proc called Init, and avoid putting any code into new. That is my current solution. | |
Ah, you're right about A, I hadn't realized that New() is called before the object's data is loaded (although it makes sense now that I think about how Read() works). Good points about B and C as well.
I guess this is definitely one of the areas the language is lacking. | |
I think the reason this is a problem for you is somewhat different than the solution you're trying to craft. I'm having trouble finding even one situation where this problem occurs.
If you're concerned about cases related to world/New() and initial loading there, I would suggest creating an object to control the world loading process, which can control in which 'stage' the world is currently in. This will allow you to stall player logins and things like that, until the world is ready. I guess what I'm saying is, show us where this is actually a problem, and maybe we can provide a solution that doesn't involve what you're suggesting. | |
This isn't about world/New(), it's about datum/New()
I clarified it for you in my original post. | |
Hicup wrote:
This isn't about world/New(), it's about datum/New() The solution to the problem is, as you've already noted yourself, entirely possible to solve by the programmer themselves. In a myriad of trivial ways, even, depending on how you want to do it. Like I initially posted, if you'd be so kind as to propose even a simple, single situation where you're encountering this as an issue, I'm fairly certain that its a case of something else actually being the culprit here. Ideally speaking, the distinction between being created and then loading properties, and just being created, should always leave an object in a state where it can either report that it is not ready for use, or be ready for use. Partially because we don't have final variables in DM (Thus no workable immutability), the choice falls on providing the datum with a mechanism to report when it is ready. You cannot avoid giving it one, if your program needs to know the difference, even if you did in fact have a flag or something to tell you that New() was being called by a Read(). So I'm back to asking, where are you encountering this as a problem? I don't mean to be rude, I just honestly can't think of a situation. | |
If it makes any difference, I'd like to bring up the syntax for creating object instances with initial variables changed to constants.
new /obj {density=1; opacity=1; icon='wall.dmi'; name="wall"} (loc) | |
Like stated in the original post, it's to make it easier to check for errors, specifically when the new proc is expecting paramaters that load does not provide. A way to tell the new proc internally that the reason there are no params, is not because of an error, but because it's being loaded.
| |
Kaiochao, that is wonderful, I will see how well that works as a possible solution, but I'm on my phone at the moment.
| |
And what's this 'load' that's calling it?
Sorry - it's just a bit confusing to follow.