I have several examples like this, which are now deprecated:
' Send first 10 characters of concatenated strings to the function
Call MyFunction(Left(string1 + string2, 10))
I’m wondering if there’s a proper API2 syntax for this, keeping it on a single line. I feel like I’m missing something obvious.
I could do this but it takes more code (and to me makes the code harder to read.)
tmpString = string1 + string2
Call MyFunction(tmpString.Left(10))
What ought to be possible is
x = (string1 + string2).Left (10)
but IIRC this has already been discussed.
There isnt
You’re not
API 2 would require you to add a temporary to be abel to do
' Send first 10 characters of concatenated strings to the function
var tmp as string = string1 + string2
Call MyFunction( tmp.Left(10) )since it wont apply an extension method to an expression result which (string1 + string2).Left(10) would require
Thanks Norman. I guess the obvious thing I was missing was the existing feedback case.
Maybe the classic functions should stay? I have no formal training in object oriented programming - is there a theoretically correct syntax for this?
[quote=497249:@Eric Bloom]Thanks Norman. I guess the obvious thing I was missing was the existing feedback case.
Maybe the classic functions should stay?
[/quote]
They are still present they just dont autocomplete
It would be nice to see an ability to do something like
x = (string1 + string2).Left (10)and this sort of style should also work if we write our own extension methods
basically an “expression” and the resulting type of that expression should be something we can extend
thats probably a decent sized change to the language & compiler
[quote=497251:@Norman Palardy]It would be nice to see an ability to do something like
x = (string1 + string2).Left (10)[/quote]
I just went through this updating one of my applications to API2. I assumed the syntax above would work and was pretty disappointed to find out that it didn’t. Instead I had to break what I used to be able to do in one line into two lines.
API 1 style still works so you could have left it using the old syntax
I’m not against the API2 style, as it’s just re-learning words and syntaxes, but, other than equivalent functionalities, the only result is we lost some possibilities in the move, right?
Was it worth moving?
It’s worth noting that you can’t do this using an API1 method either:
x = (string1 + string2).Mid (10)For API1, though, the alternative methods were provided.
I always appreciated being able to EITHER use an extension method or a global method for things like that in API 1… What made the most sense to use depended on the code needed…
I still don’t see why API 2 overall is suppose to be an “improvement”. Beside such things the loss of capability and the capabilities of moving backward an forward between Xojo versions depending on systems on needs to support and Xojo version bugs a big deal to me… So I just don’t see API 2 as a net plus…
-Karen
I like that:
there is an official way to update the UI from a thread
the ordinary SQL methods can automatically use a prepared statement
I have string methods all of which are zero based
The new DateTime includes a SecondsFrom1970, so I could dispense with my subclassed Date.
[quote=497381:@Tim Streater]1) there is an official way to update the UI from a thread[/quote]Correct, the MBS plugin has had official ways to update the UI from a thread since some months/years ago 
[quote=497381:@Tim Streater]3) I have string methods all of which are zero based[/quote]For me, strings have always been 1 based and I’ve become accustomed. After all, a string isn’t an array (other than an array of bytes, but that’s not Xojo’s representation).
Didn’t Date.Totalseconds do the same?
No, that’s seconds since 1904 or so.
I searched, but found nothing that explained that (how this is possible).
These pages show how to do it:
https://documentation.xojo.com/api/databases/database.html#database-executesql
https://documentation.xojo.com/api/databases/database.html#database-selectsql
[quote=497363:@Tim Streater]
For API1, though, the alternative methods were provided.[/quote]
Actually the others were all you had originally
Eventually the extension method versions allowing you to use the dot notation were added
They are handy - but they dont cover the same use cases as the original method call style from API 1
[quote=497381:@Tim Streater]I like that:
I do too - if they do it right
Or in API 1 you could use either 
which makes no sense in many respects
OFFSET from some starting point should be 0 based
INDEXES - ie/ the position of something - should not be as its weird
We commonly never talk about “the item at offset 0 in a list” - we talk about the first item in a list
Now everything is an offset
That came from Xojo.Core.Date
It predated API 2
The only thing API 2 has brought is a unified set of names for properties
True but it simplifies matters.
Sure, but again it keeps things taut. Once I discovered about SQL injection, I was then faced with a large number of selects etc that needed to use a prepared statement. The last thing I wanted was to replace one line of SQLSelect with 10 lines of prep, bind, and select - and do that hundreds of times, thus blowing the code up. So I did something similar to what Xojo ended up with for API2 - put all that inside a method. But I only did that for strings as all my non-string values are internally generated, and I didn’t want to mess with an array of variants and figure out what type of variant I had. Now Xojo has generalised that approach so that’s more methods I’ve been able to throw out.
[quote]which makes no sense in many respects
OFFSET from some starting point should be 0 based
INDEXES - ie/ the position of something - should not be as its weird
We commonly never talk about “the item at offset 0 in a list” - we talk about the first item in a list
Now everything is an offset[/quote]
Well in software most things are an offset. With zero-based I can take the character position and that’s immediately the offset to further down the string I’m parsing - or, with HTML, excising chunks and replacing them with something else.
Yeah I know. So my app was a mixture of Date and Xojo.Core.date, in order that I could use SecondsFrom1970. When the remote end sends you a file, and you write it to disk, it seems rude not to set the CreationDate and LastModifiedDate.
I’ll assume you hadnt already just created a thread subclass that already did this that you could just reuse everywhere
Just saying that ever since ThreadAccessingUI has been around this has been a known way to do this and people have used a thread subclass and moved on
Again - they’ve just done what you described you said you didnt want to do
There is no magic here
lots of years of writing code have convinced me that both are useful in different scenarios
columns of a query arent usually thought of as 0 based
you get “the first column of the result row” not usually “the column at offset 0” 
Since I dont expect they’ll change this about the best thing they could do now is name the parameters in a way that indicates they are 0 based offsets (or zero based indexes) so the descriptions of things indicate that as a nice handy help tip at the bottom of the editor
That way at least the help tip at the bottom of the editor says
which is a bit of a lie since its an offset not an index but …
At least it would be more helpful than the current
which gives no NO hint at all that INDEX is zero based. This costs them nothing to do and helps users remember and learn these things
Not sure why seconds from 1970 is any more, or less, useful than the base of Date which is Jan 1 1904, 00:00:00 ?
Folderitem creation and modification dates is a different story
The (scarse) comments says so. 