Rewrite INI-Functions

[Valik]

Manadar, a line does need drawn in advance because we have to ask "why this but not this"? And the related "if anything why not everything"? Also there would need to be a method to it. Some things are implemented by shared code. It doesn't make sense porting out one function if most of it's implementation was done by a utility function that's going to stay behind because it's used somewhere else. But that's exactly the kind of stuff that would happen if there wasn't a clear plan in place. Then there are issues like how to organize the libraries. Heavy optimization (optimizing compiler) so that performance impact is minimal as well as ensuring compiled scripts aren't larger due to the larger libraries. It's not as trivial as just deciding to port a few hundred lines of code from C++ to AutoIt and calling it good. Any misconception that it is that simple is going to lead to problems down the road.

[jvanegmond]

I failed epically. Not enough inside knowledge, I guess..

[Xenobiologist]

To summarize the things from my point of view:

• the ticket keeps open
• the functionality of ini or property or... files should be accessible within Autoit (the functionality is still useful)
• it is not wanted that somebody non-dev implements the function in c/c++ to be included in Autoit "kernel" (If done ... then by Valik itself)
• the implementation is not going to happen soon
• developing the function in "pure" Autoit and kick it out of the "kernel" is something the devs have to decide (open)
• the general decision whether any function should be in "kernel" or written in Autoit is not that easy, because there are dependencies which have to be considered more globally - maybe there needs to be more surplus than just the lines of code the function takes

Mega

[wraithdu]

I found this library under MIT license while searching for my own project. I think it would work perfectly for AutoIt. It's very flexible, well written, and maintained. Should be very easy to integrate as well. Opinions?

SimpleIni

Edited November 5, 2009 by wraithdu

[Valik]

I've added a link to that library to the ticket. I'll look at it further when the time comes.

[NerdFencer]

If at some point somebody replaces the code for INI handling, there is one notable shortcoming that I would like to see fixed.

In many driver INF files, there are some lines of data without an equals operator which are not found when dealing with these files under the current implementation.

Although this breaks strict INI rules, it would be nice if it was supported because of its widespread use.

[Valik]

They are INI functions, not "any arbitrary format" functions.

[NerdFencer]

Yes, but when Microsoft supports it as part of its standard for driver inf files(defined as specialized INI files), its nice if the function works.

[Valik]

Yes, but when Microsoft supports it as part of its standard for driver inf files(defined as specialized INI files), its nice if the function works.

Notice the word I bolded. I've seen numerous variations of INI-like files. Some don't have section headers, some allow multi-line values, et cetera. Just because something looks like an INI file doesn't necessarily mean it is. I'm not going to add in support for arbitrary variations on INI files unless it has zero impact on standard INI file handling. If I use a library that supports arbitrary formats and it causes exactly 0 issues with standard files, I might consider it. Otherwise, if it's not a standard INI file, then use the File* functions.

[flyingboz]

Otherwise, if it's not a standard INI file, then use the File* functions.

Since this free for all got reopened

While I would love to see support for removing .ini file size limits with the native functions,

it is not a difficult exercise to write one's own parser for reading / writing these documents.

Might also give some a better sense of what Valik's talking about, too.

For example, my (heavily commented) IniSectionsToArray() is 32 lines,

including comments and local variable declarations.

I am totally against anything that adversely affects native Ini* functions ability to read plain ini files.

If you need something more special, write a UDF for it.

Performance isn't an issue unless you've got _REALLY_ large .ini files to wade through.

[MadBoy]

Since this free for all got reopened

While I would love to see support for removing .ini file size limits with the native functions,

it is not a difficult exercise to write one's own parser for reading / writing these documents.

Might also give some a better sense of what Valik's talking about, too.

For example, my (heavily commented) IniSectionsToArray() is 32 lines,

including comments and local variable declarations.

I am totally against anything that adversely affects native Ini* functions ability to read plain ini files.

If you need something more special, write a UDF for it.

Performance isn't an issue unless you've got _REALLY_ large .ini files to wade through.

flyingboz care to share your IniSectionsToArray() ?