Jump to content
Henry Olive

Function with 2 return values ?

Recommended Posts

function sincronizarProdutosMercado(out strDescMensagemOk: string; out strDescMensagem: string; resetProdutos: Boolean = False): Boolean;

Share this post


Link to post
17 hours ago, David Heffernan said:

no extra type safety is gained by using a record over an array

A record can mix types.  TArray<Double>, not so much, even if I can stuff integers into a double.

It is a risky approach to bet on accessing the correct index of an array, instead of a named value in a record.

 

But - both methods have their use.

Share this post


Link to post

I think the safest way is to have two 'out' parameters with a Boolean return value that indicates they're both valid.

 

If you have a bunch, then you should return them in a class instance as the RESULT of the function call.

 

 

 

Edited by David Schwartz

Share this post


Link to post
1 hour ago, Lars Fosdal said:

It is a risky approach to bet on accessing the correct index of an array, instead of a named value in a record.

Agreed, but the issue is not one of type safety, as you stated.

Share this post


Link to post
56 minutes ago, David Schwartz said:

return them in a class instance

If you return a class instance, you have explicit memory management to deal with (remember to dispose of the response), unlike records where it is handled implicitly.

Share this post


Link to post
2 minutes ago, Fr0sT.Brutal said:

pliers or screwdriver?

Screwdriver - what type?  Flat, Philips, Pozidriv, Hex, Torq? 😛

Share this post


Link to post
1 hour ago, David Heffernan said:

Agreed, but the issue is not one of type safety, as you stated.

True. I should have said type flexibility.

Share this post


Link to post
10 minutes ago, Lars Fosdal said:

Screwdriver - what type?  Flat, Philips, Pozidriv, Hex, Torq? 😛

With changeable bits. I think it perfectly maps to Generics 😄

 

  • Haha 1

Share this post


Link to post
2 hours ago, Lars Fosdal said:

Screwdriver - what type?  Flat, Philips, Pozidriv, Hex, Torq? 😛

I once went into our local hardware store to buy a posidrive screwdriver, because I had to do something with a bunch of posidrive screws. The guy in the store scoffed at me and said that they didn't stock posidrive screwdrivers because posidrive screws were a stupid idea.

 

This store is no longer in business.

  • Like 1
  • Haha 1

Share this post


Link to post
16 hours ago, Lars Fosdal said:

If you return a class instance, you have explicit memory management to deal with (remember to dispose of the response), unlike records where it is handled implicitly.

Either you're going to keep adding parameters to the method's signature, or you're going to have to collect them into an object. Take your pick.

 

Mark Seemann calls these Parameter Objects or Façade Services

 

They typically start out as a collection of fields passed around as related parameters, but usually end up taking on a life of their own and become Façade Services.

 

And ... if you set up an interface that the class implements, then this won't be a problem.

Edited by David Schwartz

Share this post


Link to post
3 hours ago, David Schwartz said:

And ... if you set up an interface that the class implements, then this won't be a problem.

My problem with interfaces and their implementation in a class is that you have to type everything twice (copy, of course). I wish there was some hybrid kind of class that simply adds reference counting on top of normal class functionality. Basically the compiler could autogenerate an interface declaration for the public methods of a class and modify the constructors to return that interface instead of the class.

 

Hm, didn't we have reference counted classes in the ARC compiler?

Share this post


Link to post
22 minutes ago, dummzeuch said:

I wish there was some hybrid kind of class that simply adds reference counting on top of normal class functionality

And I wish there were pure interfaces without that refcount boilerplate. Two completely different models (required set of methods and refcounting) were mixed into one type.

  • Like 2
  • Confused 1

Share this post


Link to post
4 hours ago, David Schwartz said:

Either you're going to keep adding parameters to the method's signature, or you're going to have to collect them into an object. Take your pick.

I sometimes use objects for parameters if they need to live on within subsystem that the called method belongs to, or when the returned object needs to live on.

I use records when I need a function to return multiple values that soon will be discarded. I sometimes use methods within the record declaration to simplify the most common parameterizations.

Share this post


Link to post
16 hours ago, David Heffernan said:

... said that they didn't stock posidrive screwdrivers ...

The struggle is very real. I have a very large collection of screwdrivers and bits of assorted sizes and types.

Share this post


Link to post
1 hour ago, Fr0sT.Brutal said:

And I wish there were pure interfaces without that refcount boilerplate. Two completely different models (required set of methods and refcounting) were mixed into one type.

We do. They're called 'abstract' classes. They've been around for quite a while now. Similar semantics as C++ but the compiler isn't as strict.

 

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Classes_and_Objects_(Delphi)

 

Edited by David Schwartz

Share this post


Link to post
28 minutes ago, David Schwartz said:

We do. They're called 'abstract' classes.

No, that's not the same. To use an abstract class, your implementing class must inherit from it. A pure interface does not require that.

Share this post


Link to post
38 minutes ago, David Schwartz said:

We do. They're called 'abstract' classes

We could if Delphi supported multiple inheritance or mixins. But now - no, they're not much more than usual classes.

Share this post


Link to post
25 minutes ago, dummzeuch said:

No, that's not the same. To use an abstract class, your implementing class must inherit from it. A pure interface does not require that.

I guess I'm not clear what you're referring to. What good are Interfaces if you don't inherit from them? You cannot define any data fields in them.

Share this post


Link to post
13 minutes ago, David Schwartz said:

I guess I'm not clear what you're referring to. What good are Interfaces if you don't inherit from them? You cannot define any data fields in them.

I can declare a method parameter of some interface type and pass any class to it that implements the methods that interface defines, independently of any inheritance.

If I use an abstract class as type for that parameter, I can only pass classes that descend from that abstract class.

Share this post


Link to post
2 hours ago, Fr0sT.Brutal said:

And I wish there were pure interfaces without that refcount boilerplate. Two completely different models (required set of methods and refcounting) were mixed into one type.

With the current memory model that would be a complete disaster. The main appeal of using interfaces when doing some DI architecture is the ref counting.

And the mantra "program to an interface, not an implementation" is factually wrong: read https://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

Share this post


Link to post
20 minutes ago, David Schwartz said:

I guess I'm not clear what you're referring to. What good are Interfaces if you don't inherit from them? You cannot define any data fields in them.

Analogy: one person could have blacksmith, cooker and plumber skills (implement these interfaces) and he could easily pass professional requirements (type check) because sets of skills are defined globally (interfaces declaration). So when somebody looks for a cooker (method with parameter of that interface) the person is allowed.

Contrary, another person is blacksmith just because his father was blacksmith and taught him (inheritance). He can add some skills (implement new set of methods) but they will be personal and won't pass professional requirements (type check).

Share this post


Link to post
1 minute ago, Stefan Glienke said:

With the current memory model that would be a complete disaster. The main appeal of using interfaces when doing some DI architecture is the ref counting.

Well, they could change things to this:
 

IPureInterface = interface
end;

IRefCountInterface = interface(IPureInterface)
...
end;

IUnknown = IRefCountInterface;

and leave implicit default inheritance from IRefCountInterface.

Share this post


Link to post
1 minute ago, Fr0sT.Brutal said:

Well, they could change things to this:
 


IPureInterface = interface
end;

IRefCountInterface = interface(IPureInterface)
...
end;

IUnknown = IRefCountInterface;

and leave implicit default inheritance from IRefCountInterface.

And what exact benefit would a non-ref counted interface have? Once you pass down some you lose any control over its lifetime.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×