Why are ObjClone() and ObjDeleteProp() removed?

[iseahound]

I personally favor the ObjXXX functions, so I was hoping all of the obj.xxx methods would eventually get transferred to their ObjXXX() counterparts.

I was personally hoping for ObjHasOwnMethod().

As it stands the division between ObjXXX and obj.xxx seems rather random. I really don’t know why ObjHasOwnProp and obj.HasOwnMethod are allowed, but ObjHasOwnMethod is not.

[swagfag]

i imagine all functions will be erased in time.
ignoring personal preferences, what uses do u have for these functions?
i can think of only one: obtaining references, which u can do with instance.Base.GetMethod() or class.Prototype.GetMethod()(and others)

[iseahound]

They’re functions. I don’t care if methods get overwritten or erased, because I don’t call methods.

It’s mostly style:
obj.something.random.sixtyninefourtwentyxd.getmethod()
Or
ObjGetMethod(obj.something.random.sixtyninefourtwentyxd)

I’m using getmethod wrong but the dot operator is already heavily overloaded.

[lexikos]

Other redundant Obj functions (which mirror built-in methods of Object) were removed. ObjHasOwnProp (formerly ObjHasKey) and ObjOwnMethods/ObjOwnProps (formerly ObjNewEnum) are kept to facilitate safe inspection of objects which have redefined those methods (and the primitive prototypes, which don't have them defined).
Source: v2-changes

The redundant functions were removed because they were redundant, to reduce the "API surface area" and documentation size (if they were documented properly), and so that the author of an object can override or block them if desired. If you really want functions, you can define them yourself.

More specifically, ObjClone was removed because it only works with Object, not any native derived types like Map or Array. Map and Array define their own Clone methods, while other built-in types do not support cloning. In general, user-defined types also need some custom logic for a clone to be sane.

I have no idea why I didn't remove ObjDeleteProp earlier, with the others.

I’m using getmethod wrong but the dot operator is already heavily overloaded.

It's just a method call.

You're getting a method of .sixtyninefourtwentyxd, not of obj. Having GetMethod at the right end makes more sense for this contrived example.

On the other hand, HasProp(someObj,'property') looks closer to someObj.property than someObj.HasProp('property'). (Side note: HasProp and HasMethod are functions because they're intended to be used on everything, not necessarily just objects; and without caring about meta-functions, getters or COM objects that don't have those methods.)


I did consider that perhaps some of the methods would have been better as functions, but it was mostly while testing the primitive prototypes (like 0.base), which are very atypical, in that they do not support the methods. However, I suppose another reason to have functions rather than methods is to keep the functions for "low level" construction of objects separate from the apparent interface of every user-defined object. (That is, let the object have only methods relevant to its type or main purpose.)

[iseahound]

I think what I’m trying to ask is why aren’t functions like ObjSetBase reduced to SetBase, since they could theoretically be operated on any. Likewise, HasOwnMethod should be a function too to facilitate introspection, just like HasMethod. I never used ObjClone and I agree this function should be overwritten by the user.