Topic: Create a new Lisp data type

[irneb]

I'm bumping my head against something which causes me to loose the little hair I've got. I'm trying to implement something like an OOP interface into AutoLisp, but for that I require an ObjectType/ClassType - not simply a list / integer / real / string. I know it "can" be done, since this is exactly what the VisulaLisp ARX is doing: it creates a new Data Type for use in AutoLisp. But for the love of mike I'm not finding any way to do such in ObjectARX.

I'm unsure if trying to "extend" the result buffer type is a way to go.

[owenwengerd]

It's not possible to implement a new data type or to extend the result buffer. Why do you feel that the built in types are not sufficient?

[nullptr]

You can expose your ObjectType/ClassType to lisp via COM

[irneb]

Yep, I was finding that while searching. The resbuf doesn't allow for any "strange" data types, one can't even pass the safearray/variant types which is created by vl.arx. They cause errors as there's no translation into the resbuff.

It makes me wonder how these types are implemented inside vl.arx. Not to mention those Com object types.

The reason I'm finding the built-in types insufficient is many-fold. As an example: BigNum would at best become a list of integers if used as present. If I can change it to a specialized type it might be possible to implement overrides for some functions like + - *, etc. But if it stays a list, there's next to no possibility for such.

I suppose the short answer is to simply make the C++ functions / objects COM accessible so they can be opened from the lisp side of things. That's sorry, since COM is not always available (e.g. Mac).

[owenwengerd]

If you implement a suitable management system to ensure that the object lifetimes and scopes are synchronized with the lisp environment, you can use the RTENAME type as a generic pointer to anything you want it to point to. It's not possible to provide generic overrides of built in lisp functions, though, because the overrides won't be able to handle arguments of unsupported types. However, you can expose your own equivalent functions that work with your own "custom" type.

[irneb]

That's the idea yes. To continue the BigNum example, I could overwrite the + defun and have it overloaded inside C++ / or even just call different functions depending on the data types in the resbuf. But if I implement the BigNum return type as a list data type, then it might clash with a future idea (like scalar addition to vectors).

The principle is that you should be able to type the following into lisp:

Code - Auto/Visual Lisp: [Select]

(+ (expt 2 16) (expt 2 16)) ; Returning something like a <BigNum + #FFFF #FFFF . nil>
(+ '(1 2 3) 4) ;Returns (5 6 7)

The ename idea is interesting. Could I create a temporary ename and tie it to a BigNum object perhaps. I'm thinking something like a dictionary. Though I don't want it saved into the DWG though. Is there some sort of entity type which is volatile? I can't think of any. If such is possible, the memory management could be handled by a dispose on the entity.

[owenwengerd]

Could I create a temporary ename and tie it to a BigNum object perhaps.

You can "create an ename" like this:

Code: [Select]

BigNum myNumber;
resbuf rbEname {NULL, RTENAME};
rbEname.rlname[0] = (LONG_PTR)&myNumber;
rbEname.rlname[1] = 1234; //extra space, maybe a checksum or something?

[irneb]

Thanks, I'll give that a shot!