<< Mr. Young, I am not a native English speaking one and I certainly don't feel yet all nuances of the language. If I was rude it was unintentionally and I beg your pardon. I appreciate your efforts for making a reliable product to all
us. However, everything you write raises concerns for the fate of projects that depend on one person. >>

No, you were not rude at all.  I was simply trying to explain the delays on certain features, and just got a little too detailed about the specifics of the reasons for the delays.

As for the "one person" issue, we've been in business for 20 years and have out-lasted quite a few companies that involved more team members.  In fact, our small size allows to keep going when other larger companies have exited due to a lack of revenue.

But, we would gladly hire more people if it were possible.  It's just the nature of the Delphi 3rd party market - it's very difficult to increase revenue in the face of a declining market, and our products simply have not really appealed much to those outside of the Delphi market.

<< As for anonymous (lambda-, arrow- etc.) functions, they are perfectly fit correspondent javascript entities, so it shouldn't be hard for transpiler to translate them. Furthermore, they're very useful things, especially as callbacks (event handlers etc.), and they do already exist in other pascal-to-javascript transpiler product, so it's obviously possible. I really hope that someday you will implement them too. >>

Absolutely, they are certainly not tough to implement.  But, so are the hundreds of other features that are competing for the same amount of development time, hence the reason why they aren't available yet.  That's what I was trying to explain in my original reply.  All of this is a market/revenue issue, not really a technical one.

Tim Young
Elevate Software
www.elevatesoft.com

erickengelke wrote:

> I'm not a big fan of Lambas, I think they make code much less readable.

No, they're not, Erik. If you use lambdas properly, they make code much shorter at the very least. And short code usually is more readable than bloated. It's pascal after all, it's bloated by design, and it's not possible to make it totally unreadable like brainf*ck.

> While it feels like a pain to create named functions, trust me, I've done many, one of their benefits is that they are less error-prone because you can concentrate on them rather than as a subclause, like this comment in this run-on sentence.

I do programming on Delphi since early 90-s and was in top-50 best Delphi programmers on Brainbench in 1998, so I know a little about this language.

> Also, the variable inheritance of Lambas can be confusing and lead to coding errors.

You just have to remember that they own everything what surrounding code owns, including Self, parameters and function local variables. So when called they "remember" their surrounding environment. It's very handy feature. I'll give you example in couple of minutes.

Let's talk about mORMot and EWB. I guess you know a bit about this subject. You gave us 5 versions (I'm not kidding you, there are literally 5 different versions of ewbmormot.pas in the archive, not counting ewbmormot1.pas) of the glue code and I don't know which of them is the proper one. Anyway, the most recent one didn't work properly for me and I don't understand why you do memory management stuff in garbage collector environment. Em... Well, I think you will get the point of using lambdas (closures to be precise) from this code (it's from typescript version of mORMot client):

   private httpRequest(url: string, httpVerb: string, sendData: any, callback?: serverResposeCallback, asynchronous?: boolean){
     var XHR: XMLHttpRequest = getXhr();
     XHR.onreadystatechange = () => {
       var This = this;
       if (This.isCompleted(XHR)) {
         if (callback) {
           callback.call(This, XHR.status, (httpVerb !== This.POST_HTTP_VERB) ? XHR.responseText : XHR.getResponseHeader('Location'));
         }
       }
     };

How you would suggest me to rewrite this code in EWB? How can I pass a callback given as parameter to any external named method, which in turn is called as a callback by async handler of onreadystatechange event? There is no short nor simple, nor elegant solution without using lambdas (closures in this example).

<< How you would suggest me to rewrite this code in EWB? How can I pass a callback given as parameter to any external named method, which in turn is called as a callback by async handler of onreadystatechange event? There is no short nor simple, nor elegant solution without using lambdas (closures in this example). >>

What are you trying to do with the AJAX request that you can't use the TServerRequest component for instead ?

https://www.elevatesoft.com/manual?action=viewcomp&id=ewb2&comp=TServerRequest

Typically, you would simply hook an event to the OnComplete event and handle the completion of the request there:

https://www.elevatesoft.com/manual?action=viewevent&id=ewb2&comp=TServerRequest&event=OnComplete

The main "rule of thumb" with EWB is to first see if something can be done with just EWB, and then only resort to JS if that isn't the case.  There isn't much that isn't possible right now, and once we ditch IE9 as the baseline browser, that will allow me to put in the missing bits, which are primarily things like the form-data support, file readers, array buffers, etc.

Tim Young
Elevate Software
www.elevatesoft.com

<< ooptimum wrote:
However, everything you write raises concerns for the fate of projects that depend on one person.>>

I think you'll find that many component vendors (not all) are one person teams.  Behind many good software products are also one person teams.  Personally, I think this makes them more flexible and responsive to customer needs.

I have found that many software companies as they grow bigger care less and less about customer support and become more focused on revenue.  Smaller companies are much more amenable.  So I cheer on the one person teams!

= Steve

Tim Young [Elevate Software] wrote:

>What are you trying to do with the AJAX request that you can't use the TServerRequest component for instead ?

I know about TServerRequest. It was just an example of code where the use of lambda functions is not just reasonable and visually appealing, but also dramatically reduces the code. Without them, this code turns into a cumbersome construction, which hard to understand from the first sight and it's not easy to support later on.

In fact, in my project I have to deal with a mORMot backend. I know that Eric wrote a client lib for mORMot along with his book. But his code for some reasons does not work for me. I have no time at the moment to fix it. That is why I took a working client from here: https://github.com/esmondb/mORMot-Typescript-client . But then I decided that the code there is quite small and it should be simple to rewrite it on pascal, just for learning its internals and to get rid of external scripts. But in the course of the work I came across things that are not easy to rewrite without rethinking the algorithm and complicating the code. Of course, one can recall that inside everything eventually turns into javascript and use some JS magic, but these tricky tricks are dirty hacks from the Pascal's perspective. For instance, I can assign a client's callback as a property to the method's reference object (i.e. Function obj in js) created by CreateMethod(), and then use it from the method itself, thus eleminating need in some artificial containers assigned to each async call to XHR. You better take a look at this client and try to rework it yourself. It's hard to me to explain it in few sentences, and it's good challenge, IMO.

On 23/06/2018 3:04 PM, Steve Gill wrote:
<snip>

> I have found that many software companies as they grow bigger care less and less about customer support and become more focused on revenue.  Smaller companies are much more amenable.  So I cheer on the one person teams!
>

Well said, Steve.  I'm part of a 2 half-persons team.

So you are a biased one, Jeff. On the other hand, if you provide some service, it perfectly ok to be a one-man-company, but if you are a tool-maker, it's another story, IMO. &#1057;onfidence in the future for the consumer - that's what's important.

ooptimum wrote:

> Confidence in the future for the consumer

I have run a software company for twenty years, providing services and support to some big organisations over time. I have seen competitors come and go, and we have occasionally faced the "but you are only small" issue, and I always say that they can probably rely on us more because we really care about it because it is our lives. Big companies chop and change and drop products without a thought. And rightly so probably. But one-man-shops have shown an amazing level of persistence over time. The key is having a sustainable business model, and customers who help sustain by paying the annual fees. Elevate have superb support, and very solid products. I've said before that I often find myself wanting to do some thing, working out my ideal way to do it, and then finding that it is already provided in the product.


--

Matthew Jones

<< I know about TServerRequest. It was just an example of code where the use of lambda functions is not just reasonable and visually appealing, but also dramatically reduces the code. >>

I don't think you are correct here.  In terms of code, the only difference between a lambda and a method is the class prefix on the method.  The rest of the code should be entirely the same, or almost entirely the same.  Also, considering that most callbacks want to do things with class instances that already exist, I'm not sure that you're really buying yourself any extra convenience.

<< For instance, I can assign a client's callback as a property to the method's reference object (i.e. Function obj in js) created by CreateMethod(), and then use it from the method itself, thus eleminating need in some artificial
containers assigned to each async call to XHR. >>

"Artificial containers" in this case are class instances that are probably already present somewhere, so a) they're not artificial, and b) they're probably the instance that you want to target as the completion point after the server request.  This is like complaining about having to define event handlers for controls as methods of the container form.  Why would you define them as lambdas when they make much more sense as methods of the container form ?

The only time that I can think of when you wouldn't want to use methods is if you simply wanted to do something really basic like display "Done !" in a message dialog.

<< You better take a look at this client and try to rework it yourself. It's hard to me to explain it in few sentences, and it's good challenge, IMO. >>

I'll see if I can take a look, but I suspect that it's a lot easier than you think once you wrap the functionality in a class.

Tim Young
Elevate Software
www.elevatesoft.com

<< So you are a biased one, Jeff. On the other hand, if you provide some service, it perfectly ok to be a one-man-company, but if you are a tool-maker, it's another story, IMO. &#1057;onfidence in the future for the consumer - that's what's important. >>

Okay, so what exactly is your concern here ?  As I said, we've been in business for 20 years and don't have any intention of going anywhere, so how much more needs to be shown that purchasing one of our tools is a good long-term investment ?

Tim Young
Elevate Software
www.elevatesoft.com