ID:142087
Aug 26 2008, 5:22 am
|
|
client This isn't really a problem as such, but is the ":" in O:clicked alright to use? Seeing as how the istype()s limit the Click(O) to either a turf or an obj, and since both those have clicked() procs, I don't see any problems with this. I had a read of the Guide and the Reference and the good-old F1 menu and couldn't find anything to the contrary. Any thoughts and/or advice for improvement would be greatly appreciated! | |
|
Aug 26 2008, 5:31 am
|
|
Kaioken
 |
Since nothing should stop you from using . instead, no, it's not okay. And BTW the F1 menu is the Reference.
|
Kaioken wrote:
Since nothing should stop you from using . instead, no, it's not okay. You're right. I did try the "." in the first place, but since I hadn't set up arguments for the objs or turfs in question in Click(), it was kicking up undefined proc errors. ":" worked and wasn't causing any bugs that I could tell, I thought it would be ok to use. I've got it sorted now, so thanks. And BTW the F1 menu is the Reference. Indeed it is. It seems like I'm on some kind of imbecilic roll today. Good times. | |
Short answer: No.
Long answer: Yes, but there's no reason to do it that way. The line: Click(O) can be changed to: Click(atom/O) to properly type the variable. (This assumes, of course, that you put the clicked() proc under /atom/clicked() instead of defining it twice under each of /turf/clicked() and /obj/clicked().) | |
The main issue with that approach is that the clicked() for the obj does something entirely different to the clicked() for the turf. Although I suppose a type check in an all-purpose clicked() proc would suffice so it could handle both objs and turfs.
| |
Milo87 wrote:
The main issue with that approach is that the clicked() for the obj does something entirely different to the clicked() for the turf. Although I suppose a type check in an all-purpose clicked() proc would suffice so it could handle both objs and turfs. Or you could have a general atom/proc/clicked() which does nothing, but then override it for turf/clicked() and obj/clicked() | |
This is is all quite ridiculous to begin with since he should really just be using the uh, built in atom/Click() proc anyway, and override it for the types needed.
| |
The way I (and possibly many others) see it, using the : operator is never recommended unless there is no other possible way around it (although such a situation I've never actually come across).
| |
Ephemerality wrote:
The way I (and possibly many others) see it, using the : operator is never recommended unless there is no other possible way around it Yeah, because : is less safe than . and so you better use the latter when possible. The difference between them is that . does more compile-time checking and : checks incompletely. You're meant to use : only 'on occasion' but . 'always'. (although such a situation I've never actually come across). They're indeed quite rare (but they exist). | |
I can't remember why now, since that is pretty obvious, but there was a reason why I used a custom proc. I'm sure if I go back and check now, I still won't remember the reason and use Click() anyway...
| |
One such rare situation is trying to access the objects in the overlays/underlays variable since they are stored as special format.
| |
Milo87 wrote:
> client This isn't really a problem as such, but is the ":" in O:clicked alright to use? Seeing as how the istype()s limit the Click(O) to either a turf or an obj, and since both those have clicked() procs, I don't see any problems with this. I had a read of the Guide and the Reference and the good-old F1 menu and couldn't find anything to the contrary. To add onto what's been said, the colon operator is a runtime search of the object's methods or properties, whose incorrect use at compile-time is rarely caught and leads to errors at runtime instead. The colon operator is frowned upon because it promotes ambiguity, which is counterintuitive in an object-oriented language, especially in situations where its' use is entirely unnecessary. There are several ways to do what you require instead of using the colon operator here, which include what Jon88 and Kaioken have suggested: defining a generic /atom/clicked proc and overriding that as necessary, or utilizing each atom's Click proc as needed, as opposed to using client/Click. You could also simply use two if statements within client/Click to prototype the datums you need on the fly, but I'm not going to ram one down your throat since I lack the authority and experience to pass judgment on what's best programming practice. | |
