TMap Problems. 🤔

[MagForceSeven]

@Drakgoku

If you find a solution to the Struct error, I can try to do it with Structs.
Thanks also for your advice.

No, there is no solution for this that allows you to use both a structure and TSoftObjectPtr because TSoftObjectPtr is specifically designed for use with UCLASS’s which must be derived from UObject.

@Drakgoku

If you consider that it is not necessary, you are not considering my functionality. What am I loading?.. well, things.

And no one can give you good help if you withhold information. Nothing about your initial post indicated any functional requirements beyond “this doesn’t compile”.
If you would like to provide more details about what you’re actually trying to build and having problems with I’m happy to help, but beyond that the below responses are the only engagement I’m going to make in the rest of this thread’s topics.

//------------------------------------------------------------------------------------------
As others have stated now, if you’re just going to complain about the limits of the engine maybe you should stop. Every piece of advice you’re going to get on this forum, for every problem you encounter, is going to be: “Don’t fight the engine”. If you’re not actually going to take the advice of the community, I don’t know what help we’d ever be able to give you.

@Drakgoku

My comment about the OOP was based on the vision of those of us who work every day with various platforms, engines and languages and need to constantly be in each area. Even in individual projects we tend to touch multiple areas.

In those scenarios, sticking tightly to very specific conventions can limit long-term flexibility and adaptability.

I get the desire to simplify ones work this way, but it seems ultimately self defeating to me. When working in a particular language you should use the tools of that language to their fullest to most easily solve the problem. To limit solutions in one language because it would mean using a language feature that’s not in the subset of features present in all languages is, quite frankly, absurd.

@Drakgoku

Good OOP practices promote maintainability and adaptability.

Guess what? Good functional practices promote maintainability and adaptability too! C++ is a multi-paradigm language. Don’t ask how to hammer in a screw and then complain when people tell you to use a screwdriver instead.

[Drakgoku]

I understand your position, however I think there are points where we are not completely understanding each other. Let’s go in parts:

No, there is no solution for this that allows you to use both a structure and TSoftObjectPtr

The proposed OOP solution works perfectly, unlike being limited to native UE5 structures that clearly did not apply here. The object-oriented approach clearly provides the necessary flexibility in this case.

Insisting on using structures when I have already demonstrated that they did not solve the need denotes a lack of understanding of the problem.

I don’t know your experience in UE5, but categorically state that “saying there is no solution to the problem” when I proposed a viable one doesn’t make much sense.

And no one can give you good help if you withhold information. Nothing about your initial post indicated any functional requirements beyond “this doesn’t compile.”

At no point did I just say “this doesn’t compile.” I extensively detailed the functional requirement and why it was causing compilation problems. I suggest you reread the thread to understand the context before making unsubstantiated claims.

The requirement to return an interface map was 100% clear from the start. Pretending that implementation details are necessary denotes a very limited understanding of modular design.

As others have stated now, if you’re just going to complain about the limits of the engine maybe you should stop. Every piece of advice you’re going to get on this forum, for every problem you encounter, is going to be : “Don’t fight the engine”

Pointing out a specific engine limitation is not a complaint, it is identifying an area of opportunity. If UE5 can’t trivially solve something as basic as returning an interface map, it seems valid to mention it as feedback.

I used OOP due to a specific lack of UE5. Optimizing the use of available tools is not “fighting the engine.”

To limit solutions in one language because it would mean using a language feature that’s not in the subset of features present in all languages is, quite frankly, absurd.

At no time do I intend to limit the solutions in UE5 with OOP. That argument doesn’t make sense. I need a specific functionality that I was able to solve in a standard way with OOP. I don’t see the point in taking advantage of C++ capabilities when the native UE5 resources don’t directly apply.

It is interesting that you consider that touching UE5 and C++ is enough to understand all programming and you consider that applying OOP is absurd, although in reality they are only part of a wide spectrum of areas and languages, such as web development, applications and the cloud. Each of these fields has its own complexities and challenges, so it is important not to underestimate OOP, the diversity and breadth of programming as a whole.

Guess what? Good functional practices promote maintainability and adaptability too! C++ is a multi-paradigm language. Don’t ask how to hammer in a screw and then complain when people tell you to use a screwdriver instead.

Nobody rules out good functional practices. But OOP better solved the need in this specific case. Using the appropriate tool for the requirement is not “hammering a screw.”

And standards exist for both functional and object-oriented programming. Please avoid making unsubstantiated claims as what you consider to be good practice does not mean it is standard. Fighting OOP standards doesn’t make much sense.

[Drakgoku]

First of all, thank you all for the experience contributed to the post. I understand that some perceive my approaches as “complex”, not at all.

OOP, however, solves “any” need where native tools have limitations and I urge everyone to use best practices for modular projects. Whether you have trained with C++ or another language. Even Php which is an old language uses OOP. A degree in Java, C++, or any other related language will open your mind.

Object-oriented programming has universally established principles that provide flexibility and adaptability.

If 100 people tell me that I have to comply with the canons of society (thin, tall, athletic, intelligent…), it does not mean that all 100 people are right.
Someone might think “but you’ve been told 99 times that you have to be this way.”
Doesn’t mean that’s right. It is an argumentum ad populum fallacy.

[Drakgoku]

Yesterday I had a talk with some experts with UE5 of more than 6 years and some GameDevs professors from universities. I have free time to do a broadcast with some of them.
Well, I can say that from the very advanced experts and according to what these experts say about AAA companies, they rarely publish in the forum, since, with the agreement they have with EPIC, they directly call EPIC or take a a couple of EPIC programmers and they take them to that company and they solve almost any type of problem or make a custom plugin tailored to their needs, instead of investing it in the forum.

Based on the teachers, functional programming, despite being old, for modular projects, would not make sense and would be an inconvenience and in the long run a waste of money in UE5. Therefore, for large projects, object-oriented programming will always be more flexible, modular, and simpler. Therefore, it is important to have a minimum of knowledge.

I showed you this post about using UE5 specific things and functional programming, why? I have free time and I like the diversity of opinions. They put their hands on their heads and told me textually:
“There are all kinds of people and everyone does it as they “want” and that doesn’t mean it’s right.”
“There are many people with many years of experience who have become ‘stuck’ using old practices, it is difficult for these people to tell you that they are doing it wrong”
“If you know how to do the right thing and you observe that others do not do the right thing because they follow old practices, why argue with this type of people? If they want to drown in the well, there is no need to do anything.”
“Using language-specific things can ‘sometime’ be productive, but anything specific can be done with OOP”

I would like to urge everyone to do it with OOP, but since I received good arguments from some experts in yesterday’s talk, do it as you want. I hope I don’t have the luck of finding myself in the same project with those from functional programming and engine-specific things.