[NUG] *Re: API 2.0

[npalardy at airenet.com]

> On Mar 13, 2019, at 3:55 PM, Jon Ogden via Nug <nug at xojousers.com> wrote:
> 
> 
> 
>> On Mar 13, 2019, at 2:40 PM, npalardy at airenet.com wrote:
>> 
>> 
>>> On Mar 13, 2019, at 1:36 PM, Jon Ogden via Nug <nug at xojousers.com> wrote:
>>> 
>>> Most of the Xojo framework will be set aside AFAIK. Auto is deprecated and Variants are back. Like you said Text is deemphasized. Xojo.Net.HttpSocket has been replaced by URLConnection. Etc. 
>> 
>> URL connection IS just Xojo.Net.HTTPSocket with  some bug fixes & tweaks
>> 
> 
> Yes, but I idon’thave to call Xojo.Net and the Xojo.Net socket needed to read stuff from a memory block or something.  It was a pain if I remember right.

Much of that was simply attempts to make it clear that sockets send and receive binary data not "strings" (ie textual data)
Its why in the old socket if you expected to read "textual data" you HAD to call define encoding or you could get screwy results
That goes back to the dual nature of string where you could use it for textual data OR binary data (chr vs chrb)
It was handy but it also lead to all kinds of "why dont I get the text I sent" kinds of queries because the text encoding is NOT known

There really wasn't any perfect answer and the take away for everything was to go back to the dual nature - and live with all the questions (like Joe's wy are there diamonds in the Interface post)
Trust me that was not an easy decision and is in part why it took so long to arrive at

>> Strings will still have the dual behaviour BUT for textual data will basically be what Text was - just accessed using "string" apis and methods
>> 
>> There are a lot of good things in the "new framework" and where possible they'll be moved to be the new underpinnings of the the framework 
>> 
> 
> I agree.  But some things like Xojo.Timer.CallLater have some serious bugs that would suddenly pop up and cause crashes (particularly an iterating over a dictionary error).  Then other things like the Xojo.Net.TCPSockets were half developed.  Never had a .listen method.  Again had to read into a memory block.

Call later is used in ways that lead to bugs .. true
But its not buggy in and of itself
If you set a timer to do a calllater to a method on a form and before the call happens the form is closed you will get a crash
It one of those things that used incautiously can cause problems - heck I ripped out code in the IDE that was put in by other engineers for exactly this reason - the IDE would randomly crash because of a calllater 

Now what IS buggy is using WeakKAddressOf
It does not check to see if the target has disappeared and do nothing if it has

> I went and started to move things to Auto and Text and now regret it.  A pain to change it back.  I’ve been burned multiple times by the ToText method where I have data in a string that doesn’t translate to Text and an exception gets thrown.

You'd get "burned" in subtle way with string 
If you shoved that into the UI you'd get problems or diamonds
And no warning at all - at least an exception is catchable and you could try to do something sane

String will subtly corrupt its "textual data" in all kinds of nifty ways especially if sometimes you mix & match an encoded string and calls to ChrB
And there's no programmatic way for you to enforce that "this is ALWAYS text" or binary data and avoid these surprises

The only way to add that kind of enforcement is to split the dual nature into - TEXT and MEMORYBLOCK

But we know how that went over