| View previous topic :: View next topic |
| Author |
Message |
fragman
Joined: 13 Oct 2009
Posts: 1199
|
 Posted: Thu Jul 22, 2010 1:35 pm Post subject: |
 |
|
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. |
|
| Back to top |
|
 |
HotKeyIt
Joined: 18 Jun 2008
Posts: 4653
Location: AHK Forum
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Thu Jul 22, 2010 2:55 pm Post subject: |
|
|
| fragman wrote: | | Could you allow passing literal expressions such as "string" or 5 as ByRef parameter? |
Yeh, I always wondered why this hadn't been supported when default ByRef value was introduced.
_________________
 |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Thu Jul 22, 2010 9:58 pm Post subject: |
|
|
| fragman wrote: | | Could you allow passing literal expressions such as "string" or 5 as ByRef parameter? |
Perhaps, but some load-time validation would be sacrificed.
| HotKeyIt wrote: | | Logically, I think obj.x[] should be same as obj.x[""] or am I wrong? |
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. |
|
| Back to top |
|
|
HotKeyIt
Joined: 18 Jun 2008
Posts: 4653
Location: AHK Forum
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Fri Jul 23, 2010 12:36 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
HotKeyIt
Joined: 18 Jun 2008
Posts: 4653
Location: AHK Forum
|
|
| Back to top |
|
|
kraker148
Joined: 12 Mar 2009
Posts: 3
|
| Posted: Sun Jul 25, 2010 11:07 pm Post subject: serializing objects in ahkL |
|
|
(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. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Mon Jul 26, 2010 3:44 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Mon Jul 26, 2010 11:20 am Post subject: |
|
|
2kraker148
For start, take a look at tinku's RichObject, there is print function:
| Code: | objPrint(ast, reserved=0)
{
if !isobject(ast)
return " " ast " "
if !reserved
reserved := object("seen" . &ast, 1) ; to keep track of unique objects within top object
enum := ast._newenum()
while enum[key, value]
{
if reserved["seen" . &value]
string .= key . ": WARNING: CIRCULAR OBJECT SKIPPED !!!`n "
else
string .= key . ": " . objPrint(value, reserved) "`n"
}
return "(" string ") "
} |
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
| Lex wrote: | | there is no ready-made function |
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.
_________________
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Mon Jul 26, 2010 1:23 pm Post subject: |
|
|
| majkinetor wrote: | | However, there is a need for standardized serialization function, probably the best via library with documentation for it included in your official docs. |
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. |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Mon Jul 26, 2010 1:41 pm Post subject: |
|
|
| Quote: | | Serializing or de-serializing an object's base is a bit of a grey area. |
What prevents one to threat base as any other object in this manner ?
| Quote: | | Some fields might not even be needed, and some types of objects might need specialized de-serialization behaviour. |
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.
| Quote: | | One advantage of including important functionality like this as a script library is that anyone can learn from, adapt or improve it. |
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.
_________________
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Mon Jul 26, 2010 10:17 pm Post subject: |
|
|
| majkinetor wrote: | | What prevents one to threat base as any other object in this manner ? |
("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.
| Quote: | | The good mechanism would involve default and user provided handlers. Then library of specialized handlers could me made for specific cases. |
That's more or less what I was thinking.
| Quote: | | 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. |
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. |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 4511
Location: Belgrade
|
| Posted: Tue Jul 27, 2010 10:04 am Post subject: |
|
|
The problem with base over-serialization can be solved by introducing guid for recognized bases.
| Quote: | | 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. |
This is one form of already mentioned thing: | Lex wrote: | | and some types of objects might need specialized de-serialization behaviour. |
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.
| Quote: | | I'm not familiar with the acronym "DI" |
Dependency Injection.
_________________
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7299
Location: Australia
|
| Posted: Tue Jul 27, 2010 2:11 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
