Dynamic Associative Array

[michael solomon]

Hi Guys,

I'm trying to create a convenient Haxe/JS for handle cookies.
As you you know, Cookies sometimes have several vars in one Cookie in this pattern: myCookie = "key1=value1,key2=value2...keyN=valueN".
So I think it's will be nice if I could to access to those vars like: cookies["myCookie"]["key1"] (cookies is a Data structure that contain all cookies)
BUT sometimes the cookie doesn't have multiple vars and it's simply: myCookie = "value" and I want to access those vars as cookies["myCookie"]
I need a Data structure that can contain Map<String, String> and String?
I tried a lot and my best shot is Map<String, Dynamic> but then I must to cast it like: cookies["myCookies"]:Map<String, String>["key1"].
p.s (and big one :D) I need to access to that structure from pure JS in the same way...

If it's impossible I just do it with function calls instead a complicated data structure... But I just trying to strech Haxe capabilities
Viva la Haxe
Thank you!
Miki

[Benjamin Dubois]

Maybe this would help
https://github.com/haxetink/tink_core#either

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Dan Korostelev]

It looks like you need ADT for your cookie values, like this: http://try.haxe.org/#Fde27

However, it's not that nice if you want to work with that from JS, because it doesn't have ADT, so you may want to expose Type.enumConstructor and Type.enumParameters for that.

среда, 3 июня 2015 г., 20:49:54 UTC+3 пользователь michael solomon написал:

[Benjamin Dubois]

Or
http://jasono.co/2014/01/09/accept-either-string-or-int-without-resorting-to-dynamic/

NB: The try.haxe example doesn't work.

[michael solomon]

Thanks you Benjamin and Dan for yours helpful answers, I took some time for tries yours different approaches and I more liked Dan's one.
But Plz explain me how I can access to my value like: my Cookie["cookie 1"]["key"] as http://try.haxe.org/#b4799 .
Thanks!

[pleclech]

You can use a switch over your enum : http://try.haxe.org/#00Cc7

Patrick.

--

[michael solomon]

Thanks Patrick, but in your example you don't use in myCookie["cookie 1"]["key"] syntax..
I want that for this: trace(my Cookie["cookie 1"]["key"]); I'll get "value"

[pleclech]

Maybe using an abstract and storing that in you map (typedef Cookies = Map<String, ACookie>;) :

http://try.haxe.org/#a0D7e

Patrick.

[Luca Deltodesco]

I think he may be looking for something that is quite simply completely typeless (a JS style Object) in which case you can do something like:

http://try.haxe.org/#59e8B

which will actually work on all platforms, but not be very efficient of course :)

[Luca Deltodesco]

though may need to do: http://try.haxe.org/#a85E9 instead in more recent haxe versions.

[michael solomon]

Thanks Patrick and Luca, yours examples very helpful.
but you little miss what I want to achive. All I need is to access to my cookies like that:
Set:
myCookie["simpleCookie"] = "simple";
myCookie["complexCookie"]["cookie"] = "complex";

And Get:
trace(myCookie["simpleCookie"]) // simple
trace(myCookie["complexCookie"]["cookie"]) // complex

And I want to be able to use this syntax in pure JS.
Thanks a lot!
Miki

[Luca Deltodesco]

... I don't understand, that's exactly what my example gave you...

[michael solomon]

Yes, I can manage with that but if I just can set like that: http://try.haxe.org/#806A0 look at line 16 plz.

[Jeff Ward]

I've been on a similar search:

https://twitter.com/Jeff__Ward/status/605926366882594817

https://twitter.com/Jeff__Ward/status/599693428893437952

And have a few other gripes:

https://github.com/HaxeFoundation/haxe/issues/4268#issuecomment-108625282

Unfortunately, Haxe higher-ups believe their language is infallible, that you can simply (lol) use Macros and Abstracts to make things work, and if you don't like it, too bad.

So the only way to get what you want is to completely bypass Haxe and write JavaScript, which you can:

http://try.haxe.org/#F1A3d

But now this code is JavaScript-only, and you start to wonder why you're using Haxe in the first place.

[Jeff Ward]

Crap, I broke my example and can't fix it in-place: http://try.haxe.org/#6E3A1

[Dan Korostelev]

what's wrong with haxe.DynamicAccess (available since 3.2) or it's prototype i blogged about a year ago http://nadako.tumblr.com/post/86393684765/haxe-working-with-dynamic-anonymous-structures-in

воскресенье, 7 июня 2015 г., 16:13:15 UTC+3 пользователь Jeff Ward написал:

[Jeff Ward]

Dan,

It's fine if you're working with a flat structure: http://try.haxe.org/#79baA

Not fine if you're nesting them: http://try.haxe.org/#30AA4

-Jeff

[Jeff Ward]

BTW, Dan works on the haxe compiler - I get the idea he hasn't programmed a day of JavaScript in his life.

[Dan Korostelev]

Because you're not using DynamicAccess as a value type. If you want nested dynamic objects, you use DynamicAccess<DynamicAccess<T>> as with any collection type. You're using Dynamic and expecting it to work as haxe.DynamicAccess.

воскресенье, 7 июня 2015 г., 16:55:26 UTC+3 пользователь Jeff Ward написал:

[Dan Korostelev]

Okay that's just an insult. I came to working on haxe compiler after adopting Haxe by porting a huge JS codebase to it.

воскресенье, 7 июня 2015 г., 16:56:38 UTC+3 пользователь Jeff Ward написал:

[Jeff Ward]

Can you show us your nested example with try.haxe.org? I can't get it to work...  (and I broke my example again!)

[Dan Korostelev]

Like this http://try.haxe.org/#26f3e ?

воскресенье, 7 июня 2015 г., 17:03:08 UTC+3 пользователь Jeff Ward написал:

[Luca Deltodesco]

I believe his 'complaint' is that you cannot have an infinitely recursive DynamicAccess. 


... Which back to my last post, is exactly why I suggested http://try.haxe.org/#a85E9 which for some reason is also not good enough.

[Jeff Ward]

Dan, now you have to specify types at all levels.

Luca, I hadn't read far enough back to see your example. Excellent, the getter casts to Dyn -- this is what all other examples seem to be missing. Thanks!

Luca's class is what literal {} should be in Haxe. Because there's no reason to have an empty anonymous structure: http://try.haxe.org/#08884

Thanks,

-Jeff

[Jeff Ward]

BTW, what I meant by that comment, Dan, is that perhaps you've been programming in strict types for so long you've forgotten the beautiful and unhindered hackery/joy/speed that is untyped Objects. Sorry that I insulted you.

[Juraj Kirchheim]

I don't know what's wrong with this: http://try.haxe.org/#61463

But if you really must have [], then it's really not that hard either: http://try.haxe.org/#7Dd3F

Still Jeff, I think you have many weird misconceptions about Haxe and about static typing. I suggest you try using Haxe for what it is, not for what you'd like it to be. I'm sorry if the similar syntax has misguided you, but Haxe is unlike AS3 and the sooner you begin to realize that, the easier life will be for you ;)

Best,

Juraj

[Luca Deltodesco]

I guess we should map empty arrays [] to something 'more useful' too, and the number 0 whilst we're at it ^.^

[Jeff Ward]

Juraj - thanks for more examples. So wait, now it depends on whether you're using [] or dot access? I'm trying to to embrace Haxe for what it is, but "what it is" is no less of a mess than a typeless language. Types just mean there are different ways to do the same thing, more ways to describe the same things, and more confusion.

Reflect.field, Map.get/set, Array[] -- why are these different ways to access the data in an object?

Investigating Haxe has only convinced me that JavaScript isn't as bad as I thought it was. JavaScipt's "everything's an object" makes sense now. It's beautiful simplicity.

And AS3's gradual typing is a truly genius improvement upon JavaScript -- typed when you want it, untyped when you don't.

Since Haxe came later, I assumed it was a further advancement of type systems. It's not.

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

[Johann]

On Sunday, June 7, 2015 at 5:54:13 PM UTC+2, Jeff Ward wrote:

Juraj - thanks for more examples. So wait, now it depends on whether you're using [] or dot access? I'm trying to to embrace Haxe for what it is, but "what it is" is no less of a mess than a typeless language. Types just mean there are different ways to do the same thing, more ways to describe the same things, and more confusion.

Types are a way to define the programmer's intent in a way that allows the compiler to check whether they're doing something unintended. Types allow to eliminate whole classes of errors and to make many other errors a lot less likely. Other useful features of types are that they allow compilers to optimize code, that they often make code more readable, and that they make the translation of code to many different languages and platforms (with efficient results) possible at all. In short, types are good for correctness, performance, maintainability and cross-platform development. On top of that, modern, advanced type-systems, like the one Haxe offers, are so expressive that often touted superficial benefits of dynamic typing (like rapid prototyping/development) can actually be matched and surpassed in addition to retaining the aforementioned benefits.

regards,

Johann

[Jeff Ward]

Johann - you're right, types are amazing for those reasons. But types are only half the story, which is why gradual typing is so amazing.

If types were the bees knees, then why are Ruby and JavaScript taking over? Why isn't Haxe exploding? The world doesn't buy it.

​

Types should be a tool -- a fantastic tool for just the reasons you stated -- but not the only tool.

[Dan Ogles]

If types were the bees knees, then why are Ruby and JavaScript taking over? Why isn't Haxe exploding? The world doesn't buy it.

That's a silly argument. You could just as easily point to Go or Rust "taking over" - both statically typed languages. Or the plethora of typed languages that compile to Javascript such as CoffeeScript.

There are benefits to typing, and there are costs as well. If you're working on a large project with multiple developers, I find a typed language to be extremely helpful and easily worth the extra bit of complexity required. YMMV.

[Philippe Elsass]

Hey Jeff, Haxe is basically all about typing - you could as well complain on the Ruby dev forum that there isn't enough explicit typing in Ruby; wouldn't that sound silly? :D

As for Haxe not exploding? Haxe community doesn't communicate (well) enough to get exposure, and devs are lazy and gregarious (employability, paralysis of choice,...).

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[francesco agati]

Hi Jeff,
i think you can use path functions in thx.core Object for inspect objects at runtime.
https://github.com/fponticelli/thx.core/blob/master/src/thx/Objects.hx

or use macros for static path

[Juraj Kirchheim]

On Sun, Jun 7, 2015 at 7:25 PM, Jeff Ward <jeff...@gmail.com> wrote:

If types were the bees knees, then why are Ruby and JavaScript taking over? Why isn't Haxe exploding? The world doesn't buy it.

Sorry, but that's factually wrong: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Not that TIOBE is an accurate metric, but Swift already having higher popularity there than Ruby is a rather clear statement. No major company has published a dynamically typed language in the past 10 years. Mozilla's Rust, Apple's Swift, Google's Go, Dart and AtScript, Microsoft's TypeScript, Facebooks' Flow and Hack ... all statically typed.

Ruby is simply on its way out. As beautiful a language it is, Ruby code is just inherently slow and unmaintainable as projects grow. All the companies that jumped on the bandwagon when Rails was hot have rewritten their stuff in Scala or something similar. The author of Groovy even admitted that had he known Scala, he wouldn't have created Groovy in the first place.

JavaScript's popularity is not based on its language design, but on its ubiquity. The creation of blazingly fast runtimes and the ensuing rise of node amplify that effect. But people have been using JavaScript transpilers for ages now, given what a train wreck JavaScript really is. And the newest major compile-to-js languages all are statically typed.

The simple issue with types is that particularly C++ (and all of its descendants) combines an unwieldy type system with the lack of type inference. That's pretty much enough to create the impression that types are awkward or unhandy, thus propagating the false dilemma of succinctness vs. type safety. Having both is increasingly supported by most statically typed languages, and thus types simply are the "bees knees" and in fact the trend of the last five years shows that everybody is starting to accept that.

On Sun, Jun 7, 2015 at 5:54 PM, Jeff Ward <jeff...@gmail.com> wrote:

Juraj - thanks for more examples. So wait, now it depends on whether you're using [] or dot access? I'm trying to to embrace Haxe for what it is, but "what it is" is no less of a mess than a typeless language. Types just mean there are different ways to do the same thing, more ways to describe the same things, and more confusion.

Reflect.field, Map.get/set, Array[] -- why are these different ways to access the data in an object?

Investigating Haxe has only convinced me that JavaScript isn't as bad as I thought it was. JavaScipt's "everything's an object" makes sense now. It's beautiful simplicity.

And AS3's gradual typing is a truly genius improvement upon JavaScript -- typed when you want it, untyped when you don't.

Since Haxe came later, I assumed it was a further advancement of type systems. It's not.

Just one thing: How is Haxe's distinction between objects and Map different from Ruby's distinction between objects and Hash? In Ruby you `object.send("field=", value)`, in Haxe you `Reflect.field(object, "field", value)`. There is simply a fundamental difference between the property of an object and a value stored under a key and all major languages except ECMAScript respect that ... even PHP!

I will spare you challenging the rest of your post. Instead, let's go into the example on your blog, in an attempt to give advice that is more hands-on. The answer to your problem is ridiculously simple, only you don't seem to see it, because you obsess over that which you cannot seem to have. So you want this to work:

```

var config = {

  name:"foo test",

  values:[1.2, 3.5]

}

config.timestamp = 1431797453;

```

Well, here we go:

```

var config = {

  name:"foo test",

  values:[1.2, 3.5],

  timestamp: 1431797453

};

```

Bam! Was that complicated? No! What's the issue here? You have no problem with the fact that you have to declare the config variable to use it, do you? Well, the same goes for the field. You don't have to specify any types. Just declare the thing with a valid initial value and move on. Advantages:

1. The second version is actually shorter ... hooray!

2. You get type safety for free ... not that you care, but once you've gotten used to it, you will ;)

3. Everything is declared at one single location, instead of spreading it out all through your code. You can see in one glimpse what the config looks like. The code becomes easier to reason about.

4. You don't get weird behavior because the code that is supposed to set something in the config is mistakenly run after the code that reads it. You are forced to initialize anything that the code that follows wants to access. That's only sane.

5. It compiles to a more efficient runtime representation: http://try.haxe.org/#B0A4e Look at the generated JS code. The config object is not even created at runtime! On JS that saves allocation + indirection, on flash that saves you the dynamic access.

So for following the completely extravagant mantra of declaring stuff you want to use, which really only comes down to reordering your code a little, into a form that is actually easier to read, you get code that is both more robust and efficient than your AS3 prototype, and more significantly more concise than what a type safe implementation in AS3 would look like (don't forget you'll have to use flash.utils.Vector which is noisy to initialize). To break it down for you: the Haxe prototype already has AS3 production quality. 

Anyway, I think enough has been said on the subject ;)

Best,

Juraj

[Marcelo de Moraes Serpa]

Opening a parenthesis here to clarify something: CoffeeScript is not typed at all.

— Marcelo

[Marcelo de Moraes Serpa]

To avoid any confusion — I really meant statically typed.* It’s basically a subset of javascript, so it’s loosely/dynamically typed.

[Dan Ogles]

Oops, shows how much I've used CoffeeScript (not at all). I guess I was bucketing it with Dart/TypeScript in my mind.

[Jeff Ward]

Juraj - I appreciate your through and thoughtful response. I'll keep playing with my projects with your ideas in mind.

Again, I'm certainly not against types per se, but something about Haxe's type system definitely trips me up regularly, and slows down my workflow to the point where I question Haxe's usefulness to me. I'm doing something that's incongruous with Haxe's expected workflow, I'm not the only one, and the interesting learning is how Haxe could either evolve to support this, or actively lead devs like me away from these pitfalls.

But to your point -- "declare [everything] with a valid initial value and move on" -- it sounds good... but that's not how I approach software design. I build fast-as-I-can and refine as I go. I don't care if the first pass if trash because most implementations get re-written two or three times anyway. I want to prove the concept before circling back to put real effort into making it pretty or even "correct" (by ivory tower CS PhD definitions of correct.) In the beginnings of a project, the pain points and proper abstractions are unknown, I'd rather put minimal effort into prototyping the system, then come back and optimize and refactor the bits that clearly need work.

If Haxe doesn't support this design metholodogy, it seems like a huge problem (for me, at least.)

But again, thanks for your effort in helping me understand the Haxe mindset. And sorry Michael for hijacking this topic. ;)

[Rob Fell]

var config = {

  name:"foo test",

  values:[1.2, 3.5]

}

untyped config.timestamp = 1431797453; // TODO: interface

[Benjamin Dubois]

I don't get how the short prototyping hold if you don't have a compiler saying you "Hey you've make something stupid here".

Haxe is mainly know for game programming, I don't think Haxe could have taken on game programmer if fast prototyping is not possible.

See what can be done in only 2 days http://haxe.io/ld/32/.
Well, maybe it's not fast enough for you.

[Juraj Kirchheim]

On Mon, Jun 8, 2015 at 7:06 PM, Jeff Ward <jeff...@gmail.com> wrote:

Juraj - I appreciate your through and thoughtful response. I'll keep playing with my projects with your ideas in mind.

Again, I'm certainly not against types per se, but something about Haxe's type system definitely trips me up regularly, and slows down my workflow to the point where I question Haxe's usefulness to me. I'm doing something that's incongruous with Haxe's expected workflow, I'm not the only one, and the interesting learning is how Haxe could either evolve to support this, or actively lead devs like me away from these pitfalls.

I think the issue partially (or maybe even largely) stems from wrong expectations. Many of the AS3 "immigrants" just came to Haxe because OpenFl allows them to continue using a familiar API and they expect the language to be just as familiar. I'm sorry, but it isn't. It took me a long time to realize myself that Haxe is very much unlike AS3 (and in fact as I discovered it to be a lot better in many ways).

 

But to your point -- "declare [everything] with a valid initial value and move on" -- it sounds good... but that's not how I approach software design. I build fast-as-I-can and refine as I go. I don't care if the first pass if trash because most implementations get re-written two or three times anyway. I want to prove the concept before circling back to put real effort into making it pretty or even "correct" (by ivory tower CS PhD definitions of correct.) In the beginnings of a project, the pain points and proper abstractions are unknown, I'd rather put minimal effort into prototyping the system, then come back and optimize and refactor the bits that clearly need work.

If Haxe doesn't support this design metholodogy, it seems like a huge problem (for me, at least.)

That is pretty much exactly the way I write software. And I would say Haxe is better suited for it than AS3 for example.

Very little effort is needed to actually satisfy the type system. It's not more work to add the timestamp field to config when you declare it, then to add it at a later point. 

In Haxe a lot of the time you don't need to add types to start with, and code is still statically typed. Doing the same in AS3 you're going to be up to your ears in warnings and have untyped code instead.

For me, this is awesome. Naming things for example is hard and so when I start working on some idea, half the names are probably bad. But I don't care. As soon as I find better ones, I can use them and the compiler will tell me if I forgot to update something.

For functions that just forward half their arguments to other functions, I don't need to write down the types. I leave it to inference. If the type changes in the functions that do the actual work, the change propagates all the way out to the call site. I don't get any compiler errors in between. 

Also I often find myself just mushing together code in one huge function with nested functions, because unlike in AS3, Haxe actually type checks them. This AS3 code actually compiles (and errors ... see http://wonderfl.net/c/kxrw ):

```

package {

    import flash.display.Shape;

    import flash.display.Graphics;

    import flash.events.Event;

    import flash.display.Sprite;

    public class FlashTest extends Sprite {

        public function FlashTest() {

            function foo(s:Shape):void {

            }

            this.graphics.beginFill(0);

            this.graphics.drawRect(0,0, 10, 10);

            foo(this);

            this.graphics.drawRect(20,0, 10, 10);

        }

    }

}

```

In AS3, when you prototype stuff, you reach a point where things get too big to experiment any further and you need to create classes and what not. In Haxe no such treshold exist. You can just write as much unstructured code as you want, it will always be type safe. You can move bits around and rename things and the compiler will tell you whether something broke. This is the safety that TDD practitioners feel, only that in TDD you need to know beforehand what you are actually doing. With Haxe you needn't (although it's a good idea to figure it out eventually). Instead, you can just define some data and the compiler makes sure that all code honors its implicit structure.

Look at this example code: http://try.haxe.org/#811c8

It's a rudimentary fighting system for a lousy RPG. But it is type safe, without even a single type declaration (except for the main class of course). It even constructs type safe objects without a need for classes and you get autocompletion for them ... how great is that? You'll have a hard time to do anything like that in AS3.

Haxe simply approaches many things quite differently than AS3. Better, I would argue. But in the end, that lies in the eye of the beholder ;)

Best,

Juraj

[nico....@gmail.com]

I definitely agree with this, especially never thought of the issues renaming could cause in dynamic languages, I’m always moving and refactoring things, and I largely rely on the compiler to sort it out afterward. I really don’t see this need for dynamism, but at the same time, I’ve only ever really used typed languages, and I’m a very inexperienced programmer.

Nico

--

[James Hofmann]

Although this doesn't directly touch on the "cheaply defining dynamic objects" question, the number one thing that I found slowed me down when prototyping with Haxe, was designing new classes and methods too early. The language directly discourages that, as it's the source of most of the "explosions" of compiler errors. Persistent explosions are a signal that the architecture was prematurely factored; when you factor, there is simply more to typecheck, and when a factoring causes coupling then the checker asks you to do more legwork to preserve said coupling. If you instead simply write as much as you can stand in a single method, use POD types, and factor out the resulting excesses right at the end, then you get to zoom along. It's also a more correct workflow from a prototyping standpoint, since big inline blocks of code exist at a local minimum of design assumptions, and cut and paste within the block is a low-friction way to change those assumptions.

What makes it particularly hard to recognize and deal with this, starting from a prematurely factored codebase, is that if you decide to start inlining existing code, it gets worse before it gets better, because you have to deal with all the coupled structures at once - the compiler won't allow you to do anything else. But once it's done, everything suddenly clears up and you spot problems that weren't obvious before.

To the extent that that applies to the dynamic objects question, the compiler's preferred workflow is that you either figure out the algorithm first, or the data model first, but not mash up the two with changes of scope, parametrization, etc., because that's when the typechecker starts making life hard, while a JS, Python, or Ruby will just say "sure thing boss!"

[MJ]

I also come from as3 ( flash ) land and still investigating Haxe as language to use in our company. For me , as a programmer which use many languages in my work, such as as3, java and php , missing of normal for loops in  traditional C-style is strange and make me a little bit uncomfortable when using Haxe. I don't know why Haxe team think this loops are not neccessary or you can use macros for that and I'm sure I won't change that opinion, but for me almost every language which I know have for loop ( java, as3, php, javascript , swift etc) 

[Juraj Kirchheim]

On Tue, Jun 9, 2015 at 10:08 AM, MJ <m.jor...@gmail.com> wrote:

I also come from as3 ( flash ) land and still investigating Haxe as language to use in our company. For me , as a programmer which use many languages in my work, such as as3, java and php , missing of normal for loops in  traditional C-style is strange and make me a little bit uncomfortable when using Haxe. I don't know why Haxe team think this loops are not neccessary or you can use macros for that and I'm sure I won't change that opinion, but for me almost every language which I know have for loop ( java, as3, php, javascript , swift etc) 

Two things:

1. In that list, I consider PHP or JavaScript as good examples of bad language design and you will find that to be a widely held opinion (which doesn't make it true, but I do think it should be mentioned to put things into perspective). OTOH, neither Python nor Ruby have "traditional" for loops, nor do any Smalltalk or Lisp dialects (although you can always add them through metaprogramming, e.g. Lisp macros). And the list goes on in fact.

2. It just doesn't matter. I'm sure some people are also made uncomfortable by the lack of traditional C-style pointer arithmetic and what not. Having my 10000 hours of Haxe programming under the belt, all I can say is that at the end of the day it works really well. A lot better than any of the other languages you've mentioned (except swift, which I cannot judge).

I get that if you've only used cargo cult languages, then Haxe can make you feel quite uncomfortable. At least that's what it did to me. But I suggest you read an introduction to OCaml or Haskell to see how alien languages can be. If you consider that Haxe is in many ways closer to them that to AS3, I'd say it does an amazing job at not being entirely obscure ;)

Best,

Juraj

[Jeff Ward]

MJ, indeed, I don't understand why they don't add it just so fewer people would ask for it, but whatever - I've made my peace with the for-in syntax:

http://try.haxe.org/#3F337

[Justin L Mills]

MJ

I move seamlessly between as3 and Haxe, and I much prefer Haxe for loops, but I totally agree - it will take you time to come to this conclusion and require you just use more Haxe. Haxe for loops theory has good functional language roots, you are just preconditioned at the moment, give it a bit of time and you will agree.

Maybe you already use Haxe at a higher level than me, but it takes time to move from "normal" loops to Haxe ones and fully appreciate the Haxe way as better, so just give it a bit more time.

Best

Justin

[Justin Donaldson]

for (element in any_iterable_or_iterator){
   you_will_never_have_an_off_by_one_error_for(element);

}

[michael solomon]

Hi guys,
First of all, I'm sorry for the late response, nope, I haven't been in the caribbean, I just have a poor english(For now!) so it's took me a while to read and understand all your great replies!
Second, Jeff, I'm happy you "hijacked" my post, yours discussion was fascinating.
Third, I remind you that I need a Data Structure that I can to access him in convenient way even haxe and JS, AND I need that it can contain this(one picture equal to thousand words. isn't? :D)(wow this Google Group text editor so crap:S): I summarize your suggestion in little table and: (If I say something wrong below pls correct me - I tried all)

http://try.haxe.org/#00Cc7
This is not good good because it's not give a convenient access through js.

http://try.haxe.org/#a0D7e
This is not good good because it's not give a convenient access through js.

http://try.haxe.org/#a85E9
This is not good because it's not strictly type.

I'm still stuck, so I hope now you got what I need :)
Thanks you all! I learned so much from this thread!!!
Miki


On Wednesday, June 3, 2015 at 8:49:54 PM UTC+3, michael solomon wrote:

Hi Guys,

I'm trying to create a convenient Haxe/JS for handle cookies.
As you you know, Cookies sometimes have several vars in one Cookie in this pattern: myCookie = "key1=value1,key2=value2...keyN=valueN".
So I think it's will be nice if I could to access to those vars like: cookies["myCookie"]["key1"] (cookies is a Data structure that contain all cookies)
BUT sometimes the cookie doesn't have multiple vars and it's simply: myCookie = "value" and I want to access those vars as cookies["myCookie"]
I need a Data structure that can contain Map<String, String> and String?
I tried a lot and my best shot is Map<String, Dynamic> but then I must to cast it like: cookies["myCookies"]:Map<String, String>["key1"].
p.s (and big one :D) I need to access to that structure from pure JS in the same way...

If it's impossible I just do it with function calls instead a complicated data structure... But I just trying to strech Haxe capabilities
Viva la Haxe
Thank you!
Miki

[Luca]

On Friday, June 12, 2015 at 3:15:09 PM UTC+1, michael solomon wrote:

http://try.haxe.org/#a85E9
This is not good because it's not strictly type.

I'm sorry. but what the hell are you talking about? You want a 'fully dynamic assocaite array' that is strictly typed?  what??

[Jeff Ward]

Hi Miki,

What kind of type safety do you want in this example:

http://try.haxe.org/#a85E9

Best,

-Jeff

[michael solomon]

Lol, sorry for yours misunderstanding, I want that this data structure can get only stings or other specific data structure so if I try to inset in or object it's pop a ln error..

[Marcelo de Moraes Serpa]

Michael,

I still don’t understand what you want, exactly.

Can you actually show an example on tryhaxe with some comments inlined? Even if it doesn’t compile, it’s fine.

Cheers,

— Marcelo.

> On Jun 12, 2015, at 10:49 AM, michael solomon <miche...@gmail.com> wrote:
>
> Lol, sorry for yours misunderstanding, I want that this data structure can get only stings or other specific data structure so if I try to inset in or object it's pop a ln error..
>

[Jeff Ward]

I believe what he wants, and what is so natural with an ECMA Object, could be described as:

• A recursive StringMap, Foo, where the values are either String or Foo.
  
• Further, ideally he can access it, as in ECMA, with either the dot accessor, or the array accessor.
  
• Finally, since it's Haxe, he assumes it should be type safe (and why shouldn't he, that's what Haxe promises.)
  

This is the mindset of an ECMA coder, it's easy and natural in ECMA (aside from type checking) to stuff this in an Object, and it seems darn near impossible to realize in Haxe:

http://try.haxe.org/#CCa03

It's easy enough to say "don't use a recursive dynamic object and expect it to be type checked" -- but that's what ECMA coders use! Everything's an object. That's the beauty of it!

[Jeff Ward]

Miki,

Bottom line, I don't think you're going to get type safety on this, so your best bet is Juraj's examples, choose either dot or array access:

dot: http://try.haxe.org/#61463

array: http://try.haxe.org/#7Dd3F

Best,

-Jeff

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

[Benjamin Dubois]

I don't think he needs a recursive stringMap.

As I understand, it's first post (it's s schema confirms it) he needs a "cookie storage object" that can store either cookie (string) or cookie array and he wants to acces it by name.

Now seriously, unless you are doing a random website that need random cookie name, you must now the name you give to your cookie right ?

Why in the world should they be accessible with a string? Leave JS and the old AS2 behind you, it's filled with lot of dirt.

What I'd do:

A "CookieStorage" class is the red data structure is you schema.

 - You need a new cookie ? Just add this line to you class :

var myNewCookie = "";

You need a new cookie that is a "stack" of cookie, they are most probably related to something.

var something = {

   subCookie1 = "",

   subCookie2 = ""

}

You need several stock of cookie that have the same structure, add a typedef

typedef ACommonStackOfCookie = {

    var subCookie1: String;

    var subCookie2: String;
}

Now just add a mashCookies function that uses reflection to mash your CookieStorage to use actual cookies.

Better use a macro if you have the gut.

You will have fullytyped dot notation.
As a bonus, you will be able to use Boolean or Int (or even objects) as value, since the mashCookies function will do the serialization for you.

PS: What I have describe is just object programming, it's a emerging concept from the middle of the 20th century :)

You received this message because you are subscribed to the Google Groups "Haxe" group.