Since nothing should stop you from using . instead, no, it's not okay. And BTW the F1 menu is the Reference.

You should be able to cast O as an atom with no problems.

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.

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.

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...

Milo87 wrote:

> client > Click(O) > if(istype(O,/turf) || istype(O,/obj)) > O:clicked() > ..() >

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!

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.