Re: C# Progammer Forum for Beginners? - C# Discussion Boards

Re: Is it wrong to pass an object into a method, change something and then pass it back to the caller?

BillWoodruff6-Jan-18 7:40

BillWoodruff

6-Jan-18 7:40

Hi Marc, That makes a whole lotta sense, as your thoughts usually do Smile | :)

I also, am enjoying C#'s new Tuple facility.

I can't quite see how F# would, inherently, remove a need to have complex POCOS: if a POCO gotta have a lotta fields or properties ... ? Perhaps you are suggesting using Tuples with multiple Types like a property-bag ?

The mind boggles at thhe thought of this:

public class POCOLocoTuple
{
    public POCOLocoTuple()
    {
    }

    public POCOLocoTuple(string name, int age)
    {
        PBag = (Guid.NewGuid(), name, age);
    }

    private (Guid Id, string Name, int Age) PBag { set; get; }

    public string Name
    {
        set
        {
            PBag = (PBag.Id, value, PBag.Age);
        }
    }

    public int Age
    {
        set
        {
            PBag = (PBag.Id, PBag.Name, value);
        }
    }

    public POCOLocoTuple Clone(bool makenewguid = true)
    {
        Guid guid = makenewguid ? Guid.NewGuid() : PBag.Id;

        POCOLocoTuple newpocoloco = new POCOLocoTuple();

        newpocoloco.PBag = (guid, PBag.Name, PBag.Age);

        return newpocoloco;
    }
}

cheers, Bill

«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12

modified 6-Jan-18 16:48pm.

Re: Is it wrong to pass an object into a method, change something and then pass it back to the caller?

Marc Clifton8-Jan-18 3:03

Marc Clifton

8-Jan-18 3:03

BillWoodruff wrote:
Perhaps you are suggesting using Tuples with multiple Types like a property-bag ?

Not really, but keep in mind that my experience with FP is limited.

BillWoodruff wrote:
I can't quite see how F# would, inherently, remove a need to have complex POCOS: if a POCO gotta have a lotta fields or properties

One of the differences between imperative and functional programming is the concept of currying and partial application. Currying - you call a function with only the first subset of parameters, partial application - you create a function that itself calls a function requiring additional parameters. In either case, what you get back from currying is a function (you can think of it as "waiting for the rest of the parameters") or with partial application, you've defined a function that is "waiting for parameters").

Given that capability, the need for POCO with lots of properties (or fields in FP parlance) often becomes unnecessary. A simple example:

class BirthDate
{
  public int Month {get;set;}
  public int Day {get;set;}
  public int Year {get;set;}
}

class Horoscope
{
  public string GetHoroscope(BirthDate date);
  // Alternatively:
  public string GetHoroscope(int y, int m, int d);
}

Here, I've used BirthDate as a container for 3 fields, or without the container, as three parameters. In either case, calling GetHoroscope requires that all three parameters are known before making the call, so they're wrapped in a container or perhaps in local variables.

In F#, you don't need that. You can do this:

let GetHoroscope y m d = [implementation details]

Let's say you have a simple text-based UI (pseudo-codish):

let curried1 = GetHoroscope PromptForYear
let curried2 = curried1 PromptForMonth
let text = curried2 PromptForDay

Notice a few things here. First of all, for y, m, and d parameters, I'm passing in a function "PromptFor...", not an integer variable.

Secondly, curried1 and curried2 are functions expecting day and year, and year, respectively.

Where are the variables, fields, properties? They exist ONLY in [implementation details] -- the caller never creates a variable, never creates a container, etc.

So, one of the reasons POCO with lots of fields is not necessary is that those fields, in FP, are actually implemented as functions in FP, called as needed. While the example can be written imperatively:

GetHoroscope(PromptForYear(), PromptForMonth(), PromptForDay());

The problem here, with the imperative code, is that "how" you're getting those values is hard-coded -- there's no easy way to curry the C# method GetHoroscope. Even more interestingly, curried1 and curried2 can be returned as functions!

Currying, and partial function application, in C#, becomes a mess.

So one has to get out of the mindset of thinking of data, not as values but instead data as functions. That is NOT easy to do!

Latest Article - Code Review - What You Can Learn From a Single Line of Code

Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny

Artificial intelligence is the only remedy for natural stupidity. - CDP1802

Re: Is it wrong to pass an object into a method, change something and then pass it back to the caller?

BillWoodruff8-Jan-18 5:18

BillWoodruff

8-Jan-18 5:18

Hi Marc, Thanks for this virtual banquet of food for thought !

Clearly, I am yet unclear on the "deeper state" of the FP paradigm, but, it is very interesting.

Re: Is it wrong to pass an object into a method, change something and then pass it back to the caller?

User9874315-Jan-18 4:10

User98743

15-Jan-18 4:10

Hi @BillWoodruff, Funny you'd mention immutability. I've been reading about immutable properties and started using them in my project. These are the properties with only getters and no setters, that can only be set from the constructor. It turns out that many of my objects are like that because I tend to use a lot of classes just to hold data rather than having to make additional database calls, especially inside a loop. I hope this is the correct usage. If not, I've got a lot of searching and replacing to do.

The lack of surety in programming is part of the reason software is fragile.

Re: Is it wrong to pass an object into a method, change something and then pass it back to the caller?

Marc Clifton6-Jan-18 3:56

Marc Clifton

6-Jan-18 3:56

Except for method chaining, why would pass the same object back to the caller? Since the object is passed by reference, the caller's reference is updated. So, in your example:

SomeObj myobj = new SomeObj ( someparam = "Some Value" );
myobj = DoSomething( myobj );

the assignment is unnecessary and potentially confusing -- the reader of the code might wonder if myobj is not the same instance that is returned from the call DoSomething in which you passed in myobj

Of course, if SomeObj is struct, then it's passed by value, and yeah, you have to return the "value" for the caller to see the change.

I must say, I'm amused by all this because your question hit the bullseye of how messy method calling can be.

As a digression, think of higher level method as a workflow:

var stuffWorkflowNeedsToKnow = InitializeStuff();
DoStep1(stuffWorkflowNeedsToKnow);
DoStep2(stuffWorkflowNeedsToKnow);
DoStep3(stuffWorkflowNeedsToKnow);

And a further digression: Class-less Coding - Minimalist C# and Why F# and Function Programming Has Some Advantages

C# Progammer Forum for Beginners?

User987432-Jan-18 21:27

User98743

2-Jan-18 21:27

Are there any C# programmer forums that are more forgiving towards people who are fairly new to the language?

Where it's ok to ask questions that haven't been thoroughly researched?
Where you don't get downvoted because a question has been asked before (because every question has)?
A resource where one might even get assistance with asking the question itself?

Often times, questions are difficult to articulate due to the learner's lack of experience and unfamiliarity with the vocabulary.

I can continue doing this on my own, but the learning curve could really improve if I could ask a few questions that might seem ridiculously easy to an experienced programmer. Entire technologies has been deprecated since C# was invented, yet it's all still online as recommended best practices.