Menu
Forums
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Trending
What's new
New posts
New profile posts
Latest activity
Members
Current visitors
New profile posts
Search profile posts
Upgrades
Log in
Register
What's new
Search
Search
Search titles only
By:
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
Server Development
Habbo Retros
Habbo Development
Starlight [C#/.NET Core/Dapper]
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Joopie" data-source="post: 471661" data-attributes="member: 7030"><p>It seems I forgot the why. Yes I do agree with what you said. It can also cause weird side effects, when you need a specific method to be called first in order to do something with it. </p><p>However I find some use cases, for example this one, where such errors are minor. It's an object holding data and can be loaded in from a [ICODE]IClientMessage[/ICODE]. It doesn't do any specific logic other than that, and it should contain more than that. The infrastructure is in place that handles it.</p><p>Then there's the question what kind of logic do you really want in a constructor? Without cluttering it too much you basically only ever do the following: initialize fields and/or properties. Constructors that can cause exceptions isn't one of them (you're doing IO operations).</p><p>Another valid point is performance. This type of class gets constructed ever time you receive a packet. I find in this case performance a valid argument. The best use would be to just call the constructor directly. Second best option would be to call the parameterless constructor via Activator. The worst case scenario would be to call [ICODE]Type.GetConstructor[/ICODE]. At compile time the generic new constraint translates to the Activator. Another unexplored solution might be to use expressions, but not sure if that would be simpler/understandable.</p><p>Other benefits of using the such construction would be the (pre-)compile time checks the IDE and/or compiler gives you. You're also avoiding exceptions at runtime, because you're guaranteed to have a parameterless constructor.</p><p>Your solution wouldn't work because you still need to know the specific type on which you want to call the static method. Defeating the purpose of a generic implementation. Another drawback is testability. Static methods are a pain in the ass to test and should be avoid. Static methods are hardly ever the solutions. </p><p>Solution to avoid this type of initialing is to use a dedicated parser class that specifically constructs that data structure. Does the extra class, and thus complexity really make it better tho?</p><p>I agree such method containing side effects should be avoid, but in this case it's short of justified.</p></blockquote><p></p>
[QUOTE="Joopie, post: 471661, member: 7030"] It seems I forgot the why. Yes I do agree with what you said. It can also cause weird side effects, when you need a specific method to be called first in order to do something with it. However I find some use cases, for example this one, where such errors are minor. It's an object holding data and can be loaded in from a [ICODE]IClientMessage[/ICODE]. It doesn't do any specific logic other than that, and it should contain more than that. The infrastructure is in place that handles it. Then there's the question what kind of logic do you really want in a constructor? Without cluttering it too much you basically only ever do the following: initialize fields and/or properties. Constructors that can cause exceptions isn't one of them (you're doing IO operations). Another valid point is performance. This type of class gets constructed ever time you receive a packet. I find in this case performance a valid argument. The best use would be to just call the constructor directly. Second best option would be to call the parameterless constructor via Activator. The worst case scenario would be to call [ICODE]Type.GetConstructor[/ICODE]. At compile time the generic new constraint translates to the Activator. Another unexplored solution might be to use expressions, but not sure if that would be simpler/understandable. Other benefits of using the such construction would be the (pre-)compile time checks the IDE and/or compiler gives you. You're also avoiding exceptions at runtime, because you're guaranteed to have a parameterless constructor. Your solution wouldn't work because you still need to know the specific type on which you want to call the static method. Defeating the purpose of a generic implementation. Another drawback is testability. Static methods are a pain in the ass to test and should be avoid. Static methods are hardly ever the solutions. Solution to avoid this type of initialing is to use a dedicated parser class that specifically constructs that data structure. Does the extra class, and thus complexity really make it better tho? I agree such method containing side effects should be avoid, but in this case it's short of justified. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Server Development
Habbo Retros
Habbo Development
Starlight [C#/.NET Core/Dapper]
Top