AutoHotkey Community

Could you allow passing literal expressions such as "string" or 5 as ByRef parameter?

I don't always need the modified value, and it would be nicer to use if you didn't have to define it as a variable first.

That would be awsome
Logically, I think obj.x[] should be same as obj.x[""] or am I wrong?

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Yeh, I always wondered why this hadn't been supported when default ByRef value was introduced.

_________________

Perhaps, but some load-time validation would be sacrificed.
Haven't we already been over this? It is useful to be able to distinguish between [] and [""]. Aside from that, there's nothing particularly intuitive about treating [] as [""] or even using [""] in general. Finally, it's only loosely related to the change I was talking about.

I just don't get it why this is useful
Especially that you can't save anything in object[], only run a meta function

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

For the very reason that nothing can be "saved in" object[], it is guaranteed to always run the meta-function. If an object is used to store any arbitrary string value (including ""), making [] equivalent to [""] would exclude its use for any other special purpose. If you want them to be equivalent, you can make them equivalent via __Get.

In addition, there is no key specified with x[]:=y, so creating a key-value pair by default would be illogical. You've told it to assign the value to nothing, so it does exactly that.

FYI, in IronAHK that syntax is used to extend arrays.

Thank you very much Lexikos, that really makes sense. Now I can consider this for my scripts

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

(sorry for bad english)
thanks so much for your excellent works;
i want to ask, is possible to serialize (like in java ...) ahkL object, make it persistent, save to a file? if this is not possible now, do you support this features in future? it would be great! thanks for your interest for now.

It is possible using an enumerator and FileAppend or FileOpen(). The file format and code to create it is entirely up to you - there is no ready-made function.

2kraker148
For start, take a look at tinku's RichObject, there is print function:



This is serialization, you need reverse function to de-serialize objects.
You could try to change or utilize YAML by HotkeyIt to work with objects.

If you require to (de)serialze binary data, there are various functions on the forum that deal with binary <-> hex, mime, compress etc.. conversion


However, there is a need for standardized serialization function, probably the best via library with documentation for it included in your official docs. Most of the similar languages have something like that, either internally or via library.

_________________

I agree. I have many other priorities at the moment so will not consider working on this myself. Whether it is built-in or implemented in script, I think the most important part would be to ensure objects can define how they are serialized. For instance, objects may be strictly serialized individually allowing references between them, or have their contents nested in the output of the parent object. One object might contain strings and another might contain binary data in "string" fields. (I see that YAML supports both references and binary data.) Some fields might not even be needed, and some types of objects might need specialized de-serialization behaviour. Serializing or de-serializing an object's base is a bit of a grey area.

One advantage of including important functionality like this as a script library is that anyone can learn from, adapt or improve it.

What prevents one to threat base as any other object in this manner ?


The good mechanism would involve default and user provided handlers. Then library of specialized handlers could me made for specific cases.

Also, the perfect library shouldn't bind user to any standard like JSON or YAML but make them default only. DI can be used to keep all other mechanisms in place while allowing injection of desired serialization schema without changing the rest of the framework.

On the other hand, this might be to complicated for AHK as needs of AHK users are not similar to those of mainstream languages users despite recent popularization of AHK as general prog language. Perhaps sticking to JSON or YAML might have its merits in achieving simplicity.


This is certainly true. Aside from that it would provide good standards for saving the state of the program for debugging for users that are not interested in serialization. Debuging is important for everybody.

_________________

("Threat" should be "Treat".) I guess it would work, though perhaps not well. When multiple objects of the same "type" (objects with a common base object) are serialized, it would be a waste of time and space to serialize the base object each time. If the de-serializer doesn't know how to get a reference to the base object, it would need to create a copy for each object. Additionally, the base object may contain implementation details which are not really relevant and are more likely to change between versions than the fields used in the object.
That's more or less what I was thinking.
I'm not familiar with the acronym "DI", but I can guess what you're talking about. The serializer can handle enumerating the object's contents, recursively handling object references (and eliminating cycling references), while allowing the object (or its base) to have the final say in what actually gets serialized. It can do this by passing itself to a method in the target object, providing format-agnostic methods to write out data (like 'write field "x" with value "y" of type "z"' not 'write "field: value"').

Another grey area: object and int keys. Often (but not always) int keys are used to form a list/array, and the most intuitive way to serialize it would be as a list rather than a hash. As for object keys, I'm not sure.

The problem with base over-serialization can be solved by introducing guid for recognized bases.


This is one form of already mentioned thing:
Once a set of serialization procedures is created and you have a mean to associate particular procedure with particular key or object, this becomes just a special case.
As for object keys, perhaps guids can be used again. IF key is an object, u serialize it as a guid, then make reference to actual object serialized elsewhere. So you could for instance have key serialization and value serialization parts of whole process that are joined at the end.


Dependency Injection.

_________________

I must refrain from further discussion on this topic as I'm sure it could go on forever. I'm sure you'd all like to see the next revision out sooner...