<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Csan</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Csan"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Csan"/>
	<updated>2026-06-06T23:51:56Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_cc&amp;diff=22879</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 cc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_cc&amp;diff=22879"/>
		<updated>2009-10-08T04:02:30Z</updated>

		<summary type="html">&lt;p&gt;Csan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==''' Wiki2 Title '''==&lt;br /&gt;
&lt;br /&gt;
===Introduction===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Immutable classes are used to ensure the object state never change.&lt;br /&gt;
The concept of serialization is that applications can send and receive objects between them; this is a step further than just keeping the object alive (persistence) which is to call objects remotely, however private instances may be exposed by performing serialization.&lt;br /&gt;
Now the problem arises when serializing an immutable class and the immutability must be preserved between applications. &lt;br /&gt;
The Serialization Proxy Pattern tries to handle this kind of situation, thus the objectives are to:&amp;lt;br&amp;gt;&lt;br /&gt;
1.Investigate how the issue described above is handled.&amp;lt;br&amp;gt;&lt;br /&gt;
2.Investigate how it is designed and give details of its implementation,&amp;lt;br&amp;gt;&lt;br /&gt;
3.Investigate its idiomatic usage&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Csan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_cc&amp;diff=22876</id>
		<title>CSC/ECE 517 Fall 2009/wiki2 18 cc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_18_cc&amp;diff=22876"/>
		<updated>2009-10-08T03:56:47Z</updated>

		<summary type="html">&lt;p&gt;Csan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Introduction&lt;br /&gt;
&lt;br /&gt;
--&lt;br /&gt;
&lt;br /&gt;
Immutable classes are used to ensure the object state never change.&lt;br /&gt;
The concept of serialization is that applications can send and receive objects between them; this is a step further than just keeping the object alive (persistence) which is to call objects remotely, however private instances may be exposed by performing serialization.&lt;br /&gt;
Now the problem arises when serializing an immutable class and the immutability must be preserved between applications. &lt;br /&gt;
The Serialization Proxy Pattern tries to handle this kind of situation, thus the objectives are to:&lt;br /&gt;
1.Investigate how the issue described above is handled.&lt;br /&gt;
2.Investigate how it is designed and give details of its implementation,&lt;br /&gt;
3.Investigate its idiomatic usage&lt;/div&gt;</summary>
		<author><name>Csan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_11_cc&amp;diff=19854</id>
		<title>CSC/ECE 517 Fall 2009/wiki1b 11 cc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_11_cc&amp;diff=19854"/>
		<updated>2009-09-19T12:11:38Z</updated>

		<summary type="html">&lt;p&gt;Csan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== '''Static vs. dynamic o-o languages from the perspective of performance''' ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Typing&lt;br /&gt;
----&lt;br /&gt;
 Object-oriented programs can be analized either dynamically, i.e., based on run-time information, or statically, i.e., based on program analysis alone. Two promising optimization techniques for object-oriented languages are type feedback (dynamic) and concrete type inference (static)&lt;br /&gt;
&lt;br /&gt;
Static Object-Oriented Language ( type inference )&lt;br /&gt;
----&lt;br /&gt;
Statically-typed languages require that all variables are declared with a specific type. The compiler will then ensure that at any given time the variable contains only an object compatible with that type. By enforcing the type constraint on objects contained or referred to by the variable, the compiler can ensure calling   method error can never occur at run-time. It enforces safer, more reliable code, and increases efficiency of the resulting product as well. On the other hand, a static type system can hinder evolution of software in some circumstances. Upper classes restrict the inherited ones evolving into various form from its strict type-binding. &lt;br /&gt;
Eiffel , Java , C# , C++ , Visual Basic&lt;br /&gt;
&lt;br /&gt;
Dynamic Object-Oriented Language ( type feedback )&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
	A dynamic type system doesn't require variables to be declared as a specific type. Any variable can contain any value or object. In many cases this can make the software more flexible and amenable to change. However, care must be taken that variables hold the expected kind of object. Typically, if a variable contains an object of a different type than a user of the object expects, some sort of calling method error is raised at run-time. On the other hand , if the type of the object is not what it was originally expected to be, it may not understand the messages being sent to it. Even worse that it may be interpreted in a wrong way.&lt;br /&gt;
Smalltalk , Ruby , Python , Perl&lt;br /&gt;
&lt;br /&gt;
Performance Comparison&lt;br /&gt;
----&lt;br /&gt;
	Table. Performance comparison of type inference and type feedback.&lt;br /&gt;
&lt;br /&gt;
CounterAct&lt;br /&gt;
----&lt;br /&gt;
	Dynamic O-O languages monitors previous executions of the program to determine the set possible receiver classes. In turn , Static O-O languages computes the set of possible receiver classes by analyzing the program’s source code. This characteristics bring consideration opposed to the belief that the static O-O languages are efficient in performance. Compilers cannot predict the typical usage. With this reason, statical way shows more overhead when leading to calling methods called infrequently in case that the methods are small subset of vast method pool. &lt;br /&gt;
&lt;br /&gt;
References&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
External Links&lt;br /&gt;
----&lt;/div&gt;</summary>
		<author><name>Csan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_11_cc&amp;diff=19853</id>
		<title>CSC/ECE 517 Fall 2009/wiki1b 11 cc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_11_cc&amp;diff=19853"/>
		<updated>2009-09-19T12:10:45Z</updated>

		<summary type="html">&lt;p&gt;Csan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== '''Static vs. dynamic o-o languages from the perspective of performance''' ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Typing&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
 Object-oriented programs can be analized either dynamically, i.e., based on run-time information, or statically, i.e., based on program analysis alone. Two promising optimization techniques for object-oriented languages are type feedback (dynamic) and concrete type inference (static)&lt;br /&gt;
&lt;br /&gt;
Static Object-Oriented Language ( type inference )&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Statically-typed languages require that all variables are declared with a specific type. The compiler will then ensure that at any given time the variable contains only an object compatible with that type. By enforcing the type constraint on objects contained or referred to by the variable, the compiler can ensure calling   method error can never occur at run-time. It enforces safer, more reliable code, and increases efficiency of the resulting product as well. On the other hand, a static type system can hinder evolution of software in some circumstances. Upper classes restrict the inherited ones evolving into various form from its strict type-binding. &lt;br /&gt;
Eiffel , Java , C# , C++ , Visual Basic&lt;br /&gt;
&lt;br /&gt;
Dynamic Object-Oriented Language ( type feedback )&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
	A dynamic type system doesn't require variables to be declared as a specific type. Any variable can contain any value or object. In many cases this can make the software more flexible and amenable to change. However, care must be taken that variables hold the expected kind of object. Typically, if a variable contains an object of a different type than a user of the object expects, some sort of calling method error is raised at run-time. On the other hand , if the type of the object is not what it was originally expected to be, it may not understand the messages being sent to it. Even worse that it may be interpreted in a wrong way.&lt;br /&gt;
Smalltalk , Ruby , Python , Perl&lt;br /&gt;
&lt;br /&gt;
Performance Comparison&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
	Table. Performance comparison of type inference and type feedback.&lt;br /&gt;
&lt;br /&gt;
CounterAct&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
	Dynamic O-O languages monitors previous executions of the program to determine the set possible receiver classes. In turn , Static O-O languages computes the set of possible receiver classes by analyzing the program’s source code. This characteristics bring consideration opposed to the belief that the static O-O languages are efficient in performance. Compilers cannot predict the typical usage. With this reason, statical way shows more overhead when leading to calling methods called infrequently in case that the methods are small subset of vast method pool. &lt;br /&gt;
&lt;br /&gt;
References&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
External Links&lt;br /&gt;
&lt;br /&gt;
----&lt;/div&gt;</summary>
		<author><name>Csan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_11_cc&amp;diff=19852</id>
		<title>CSC/ECE 517 Fall 2009/wiki1b 11 cc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1b_11_cc&amp;diff=19852"/>
		<updated>2009-09-19T12:08:35Z</updated>

		<summary type="html">&lt;p&gt;Csan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;test&lt;/div&gt;</summary>
		<author><name>Csan</name></author>
	</entry>
</feed>