Coding patterns - Revision history

Hzwakenberg at 11:11, 5 July 2024

2024-07-05T11:11:27Z

← Older revision		Revision as of 13:11, 5 July 2024
Line 72:		Line 72:
	You can see such a pattern in action in <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/collection/linked_list.e?root=smarteiffel&view=markup LINKED_LIST]</tt> where it is used to collect unused cells (look at ''common_free_nodes'' which contains <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/any_linked_list_node.e?root=smarteiffel&view=auto ANY_LINKED_LIST_NODE]</tt> of which <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/linked_list_node.e?root=smarteiffel&view=auto LINKED_LIST_NODE]</tt> is a conformant heir).		You can see such a pattern in action in <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/collection/linked_list.e?root=smarteiffel&view=markup LINKED_LIST]</tt> where it is used to collect unused cells (look at ''common_free_nodes'' which contains <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/any_linked_list_node.e?root=smarteiffel&view=auto ANY_LINKED_LIST_NODE]</tt> of which <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/linked_list_node.e?root=smarteiffel&view=auto LINKED_LIST_NODE]</tt> is a conformant heir).

−	Another example is <tt>[https://github.com/LibertyEiffel/Liberty/blob/master/src/lib/kernel/internal/internals.e]</tt>.	+	Another example is <tt>INTERNALS[https://github.com/LibertyEiffel/Liberty/blob/master/src/lib/kernel/internal/internals.e]</tt>.

Hzwakenberg: moved link from Loria to GitHub

2024-07-05T11:10:22Z

moved link from Loria to GitHub

← Older revision		Revision as of 13:10, 5 July 2024
Line 72:		Line 72:
	You can see such a pattern in action in <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/collection/linked_list.e?root=smarteiffel&view=markup LINKED_LIST]</tt> where it is used to collect unused cells (look at ''common_free_nodes'' which contains <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/any_linked_list_node.e?root=smarteiffel&view=auto ANY_LINKED_LIST_NODE]</tt> of which <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/linked_list_node.e?root=smarteiffel&view=auto LINKED_LIST_NODE]</tt> is a conformant heir).		You can see such a pattern in action in <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/collection/linked_list.e?root=smarteiffel&view=markup LINKED_LIST]</tt> where it is used to collect unused cells (look at ''common_free_nodes'' which contains <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/any_linked_list_node.e?root=smarteiffel&view=auto ANY_LINKED_LIST_NODE]</tt> of which <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/linked_list_node.e?root=smarteiffel&view=auto LINKED_LIST_NODE]</tt> is a conformant heir).

−	Another example is <tt>[~~http~~://~~gforge~~.~~inria.fr~~/~~plugins~~/~~scmsvn~~/~~viewcvs.php~~/~~trunk~~/lib/kernel/internal/internals.e~~?root=smarteiffel&view=auto INTERNALS~~]</tt>.	+	Another example is <tt>[https://github.com/LibertyEiffel/Liberty/blob/master/src/lib/kernel/internal/internals.e]</tt>.

Hzwakenberg at 12:07, 9 September 2014

2014-09-09T12:07:54Z

← Older revision		Revision as of 14:07, 9 September 2014
Line 1:		Line 1:
		+	[[Category: Design Pattern]]
	Coding Patterns are a group of useful insights on how to implement things.		Coding Patterns are a group of useful insights on how to implement things.

Hzwakenberg at 18:12, 5 September 2014

2014-09-05T18:12:40Z

← Older revision		Revision as of 20:12, 5 September 2014
Line 1:		Line 1:
−	[[Category:Smarteiffel]]
	Coding Patterns are a group of useful insights on how to implement things.		Coding Patterns are a group of useful insights on how to implement things.

Ramack at 21:28, 5 March 2013

2013-03-05T21:28:55Z

← Older revision		Revision as of 23:28, 5 March 2013
Line 1:		Line 1:
−	[[Category:~~SmartEiffel~~]]	+	[[Category:Smarteiffel]]
	Coding Patterns are a group of useful insights on how to implement things.		Coding Patterns are a group of useful insights on how to implement things.

Ramack at 20:49, 4 March 2013

2013-03-04T20:49:43Z

← Older revision		Revision as of 22:49, 4 March 2013
Line 1:		Line 1:
		+	[[Category:SmartEiffel]]
	Coding Patterns are a group of useful insights on how to implement things.		Coding Patterns are a group of useful insights on how to implement things.

Ramack: 3 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

2013-03-03T21:04:27Z

3 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

New page

Coding Patterns are a group of useful insights on how to implement things.

== Singleton ==
To me, the best way to achieve a singleton is almost the standard Eiffel pattern: a singleton holder with a once function, and the pattern itself with a creation clause limited to the singleton holder. An interesting thing is that I usually make the singleton holder '''expanded''', this way I don't have to make it a singleton too ;-)

expanded class SINGLETON_HOLDER
feature {ANY}
singleton: SINGLETON is
once
create Result.make
end
end

class SINGLETON is
create {SINGLETON_HOLDER}
make
feature {}
make is
do
end
end

The other solution is the classic holder you either inherit or, preferably, insert.

Which do you prefer: expanded or insert?

== Multi-typed ==
It is becoming quite usual to have a few classes that want to "talk" to "any" class. But you cannot use the ANY class since most classes insert it and anyway it could not hold expanded classes. In that case you use a generic class, which can hold anything that ''inserts'' its generic constraint.

An emerging coding pattern is the following:

deferred class TALKABLE
feature {ANY}
talk is
do
end
end

deferred class UNTYPED_TALKER
feature {ANY}
make_it_talk is
do
end
end

class TYPED_TALK[O_->TALKABLE]
inherit
UNTYPED_TALK

create {ANY}
set_item

feature {ANY}
item: O_

set_item (a_item: like item) is
require
a_item /= Void
do
item := a_item
ensure
item = a_item
end

make_it_talk is
do
item.talk
end
end

You can see such a pattern in action in <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/collection/linked_list.e?root=smarteiffel&view=markup LINKED_LIST]</tt> where it is used to collect unused cells (look at ''common_free_nodes'' which contains <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/any_linked_list_node.e?root=smarteiffel&view=auto ANY_LINKED_LIST_NODE]</tt> of which <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/linked_list_node.e?root=smarteiffel&view=auto LINKED_LIST_NODE]</tt> is a conformant heir).

Another example is <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/kernel/internal/internals.e?root=smarteiffel&view=auto INTERNALS]</tt>.

Cadrian: other singleton solution

2006-08-31T06:35:36Z

Cadrian: first coding patterns

2006-08-31T05:49:15Z

first coding patterns

New page

Coding Patterns are a group of useful insights on how to implement things.

== Singleton ==
To me, the best way to achieve a singleton is almost the standard Eiffel pattern: a singleton holder with a once function, and the pattern itself with a creation clause limitted to the singleton holder. An interesting thing is that I usually make the singleton holder '''expanded''', this way I don't have to make it a singleton too ;-)

expanded class SINGLETON_HOLDER
feature {ANY}
singleton: SINGLETON is
once
create Result.make
end
end

class SINGLETON is
create {SINGLETON_HOLDER}
make
feature {}
make is
do
end
end

== Multi-typed ==
It is becoming quite usual to have a few classes that want to "talk" to "any" class. But you cannot use the ANY class since most classes insert it and anyway it could not hold expanded classes. In that case you use a generic class, which can hold anything that ''inserts'' its generic constraint.

An emerging coding pattern is the following:

deferred class TALKABLE
feature {ANY}
talk is
do
end
end

deferred class UNTYPED_TALKER
feature {ANY}
make_it_talk is
do
end
end

class TYPED_TALK[O_->TALKABLE]
inherit
UNTYPED_TALK

create {ANY}
set_item

feature {ANY}
item: O_

set_item (a_item: like item) is
require
a_item /= Void
do
item := a_item
ensure
item = a_item
end

make_it_talk is
do
item.talk
end
end

You can see such a pattern in action in <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/collection/linked_list.e?root=smarteiffel&view=markup LINKED_LIST]</tt> where it is used to collect unused cells (look at ''common_free_nodes'' which contains <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/any_linked_list_node.e?root=smarteiffel&view=auto ANY_LINKED_LIST_NODE]</tt> of which <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/storage/internal/linked_list_node.e?root=smarteiffel&view=auto LINKED_LIST_NODE]</tt> is a conformant heir).

Another example is <tt>[http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/kernel/internal/internals.e?root=smarteiffel&view=auto INTERNALS]</tt>.

← Older revision		Revision as of 08:35, 31 August 2006
Line 20:		Line 20:
	end		end
	end		end
		+
		+	The other solution is the classic holder you either inherit or, preferably, insert.
		+
		+	Which do you prefer: expanded or insert?

	== Multi-typed ==		== Multi-typed ==