[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Why no for table-iterator like e. g. "hashpairs"?
- From: Tim Hill <drtimhill@...>
- Date: Mon, 4 Nov 2019 16:23:05 -0800
> On Nov 4, 2019, at 5:05 AM, Philippe Verdy <firstname.lastname@example.org> wrote:
> For now, the #t operator is completely broken. Tables have to be
> segregated in applications between those used as integer-indexed
> sequences (almost only data), and those using hashed dictionnaries
> (notably all objects for their properties).
While I have my issues with the design of the # operator, its NOT completely broken; it behaves exactly as specified by the manual. Why do you claim that tables have to be segregated? And if so, why is this a problem?
> Tables are so universally used in Lua that this part should be
> urgently refactored for efficiency, stability, and predictability.
> Without it, Lua will remain a "toy", used in niche projects, it will
> too! Lua does not. Various projects that initially started with Lua
> integration have renounced and disabled this feature and prefered
> using other scripting engines (most frequently now they use
You are of course free to choose any of these languages for your projects.
> May be one way to revive Lua would be to have an implementation in
> easier to integrate and offer better integration with many more
> libraries, including with other languages like Python, Perl, SQL,
> LuaC: the standard library of Lua can perfectly be written in
> in PHP ? or in Java (for server-side integration, including in
> database engines, GIS applications, UI frameworks like the Android
> SDK, the iOS SDK, or the Windows UWP, or UX components for Mozilla
> browsers ?).