clean-up: RefArray is gone (closes: #473)
After the leftovers of the first Render-Engine implementation attempt were removed,
only one further usage of `RefArray` remains to be sorted out: the ''Session Element Tracker''.
Luckily, this one did not actually make any use of the abstraction abilities
of the `RefArray` — rather it basically stated that ''the interface is a data structure...''
After considering ''what kind of data'' can be expected to live in this structure,
it became clear that ''this will be a symbolic representation''
And thus the container can be simply switched to a `std::vector`.
This change allows to retain the existing placeholder-implementation unaffected,
while it would be possible to maintain algebraic terms here, in future.
__As an asside__: in order to decide about a suitable replacement in the Session,
I had to consier a first draft regarding the intended usage
and the prospective way of content representation
This commit is contained in:
parent
08bdb912a5
commit
1da5d57098
7 changed files with 366 additions and 480 deletions
|
|
@ -55,8 +55,8 @@
|
|||
#include "lib/p.hpp"
|
||||
#include "lib/optional-ref.hpp"
|
||||
#include "lib/util-foreach.hpp"
|
||||
#include "lib/ref-array-impl.hpp"
|
||||
|
||||
#include <vector>
|
||||
|
||||
|
||||
namespace lib {
|
||||
|
|
@ -79,7 +79,7 @@ namespace lib {
|
|||
*/
|
||||
template<typename ELM>
|
||||
class ElementTracker
|
||||
: public lib::RefArrayVector<P<ELM>>
|
||||
: public std::vector<P<ELM>>
|
||||
{
|
||||
using _Vec = std::vector<P<ELM>>;
|
||||
using Iter = typename _Vec::iterator;
|
||||
|
|
|
|||
|
|
@ -1,168 +0,0 @@
|
|||
/*
|
||||
REF-ARRAY-IMPL.hpp - some implementations of the ref-array interface
|
||||
|
||||
Copyright (C)
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by the
|
||||
Free Software Foundation; either version 2 of the License, or (at your
|
||||
option) any later version. See the file COPYING for further details.
|
||||
|
||||
*/
|
||||
|
||||
/** @file ref-array-impl.hpp
|
||||
** Some (library-) implementations of the RefArray interface.
|
||||
**
|
||||
** Being an array-like object exposing just a const ref, it is typically used
|
||||
** on interfaces, and the type of the array "elements" usually is a ABC or interface.
|
||||
** The actual implementation typically holds a subclass, and is either based on a vector,
|
||||
** or a fixed storage contained within the implementation. The only price to pay is
|
||||
** a virtual call on element access.
|
||||
**
|
||||
** For advanced uses it would be possible to have a pointer-array or even an embedded
|
||||
** storage of variant-records, able to hold a mixture of subclasses. (the latter cases
|
||||
** will be implemented when needed).
|
||||
**
|
||||
** @deprecated 5/2025 to be reworked and obsoleted — do not use further
|
||||
** @see several-builder.hpp
|
||||
** @see ref-array-test.cpp
|
||||
**
|
||||
*/
|
||||
|
||||
|
||||
#ifndef LIB_REF_ARRAY_IMPL_H
|
||||
#define LIB_REF_ARRAY_IMPL_H
|
||||
|
||||
|
||||
#include "lib/ref-array.hpp"
|
||||
#include "include/logging.h"
|
||||
|
||||
#include <vector>
|
||||
using std::vector;
|
||||
|
||||
|
||||
|
||||
namespace lib {
|
||||
|
||||
/**
|
||||
* Wrap a vector holding objects of a subtype and
|
||||
* provide array-like access using the interface type.
|
||||
*/
|
||||
template<class B, class IM = B>
|
||||
class RefArrayVectorWrapper
|
||||
: public RefArray<B>
|
||||
{
|
||||
typedef vector<IM> const& Tab;
|
||||
Tab table_;
|
||||
|
||||
public:
|
||||
|
||||
RefArrayVectorWrapper (Tab toWrap)
|
||||
: table_(toWrap)
|
||||
{ }
|
||||
|
||||
virtual size_t size() const
|
||||
{
|
||||
return table_.size();
|
||||
}
|
||||
|
||||
virtual B const& operator[] (size_t i) const
|
||||
{
|
||||
REQUIRE (i < size());
|
||||
return table_[i];
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
* This variation of the wrapper actually
|
||||
* \em is a vector, but can act as a RefArray
|
||||
*/
|
||||
template<class B, class IM = B>
|
||||
class RefArrayVector
|
||||
: public vector<IM>,
|
||||
public RefArrayVectorWrapper<B,IM>
|
||||
{
|
||||
typedef RefArrayVectorWrapper<B,IM> Wrap;
|
||||
typedef vector<IM> Vect;
|
||||
typedef typename Vect::size_type Size_t;
|
||||
typedef typename Vect::value_type Val_t;
|
||||
|
||||
public:
|
||||
RefArrayVector() : Vect(), Wrap((Vect&)*this) {}
|
||||
RefArrayVector(Size_t n, Val_t const& v = Val_t()) : Vect(n,v), Wrap((Vect&)*this) {}
|
||||
RefArrayVector(Vect const& ref) : Vect(ref), Wrap((Vect&)*this) {}
|
||||
|
||||
using Vect::size;
|
||||
using Wrap::operator[];
|
||||
};
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* RefArray implementation based on a fixed size array,
|
||||
* i.e. the storage is embedded. Embedded subclass obj
|
||||
* either need to be default constructible or be
|
||||
* placed directly by a factory
|
||||
*/
|
||||
template<class B, size_t n, class IM = B>
|
||||
class RefArrayTable
|
||||
: public RefArray<B>
|
||||
{
|
||||
char storage_[n*sizeof(IM)];
|
||||
IM* array_;
|
||||
|
||||
public:
|
||||
RefArrayTable() ///< objects created in-place by default ctor
|
||||
: array_ (reinterpret_cast<IM*> (&storage_))
|
||||
{
|
||||
size_t i=0;
|
||||
try
|
||||
{
|
||||
while (i<n)
|
||||
new(&array_[i++]) IM();
|
||||
}
|
||||
catch(...) { cleanup(i); throw; }
|
||||
}
|
||||
|
||||
template<class FAC>
|
||||
RefArrayTable(FAC& factory) ///< objects created in-place by factory
|
||||
: array_ (reinterpret_cast<IM*> (&storage_))
|
||||
{
|
||||
size_t i=0;
|
||||
try
|
||||
{
|
||||
while (i<n)
|
||||
factory(&array_[i++]);
|
||||
}
|
||||
catch(...) { cleanup(i-1); throw; } // destroy finished part, without the failed object
|
||||
}
|
||||
|
||||
~RefArrayTable() { cleanup(); }
|
||||
|
||||
private:
|
||||
void cleanup(size_t top=n) noexcept
|
||||
{
|
||||
while (top) array_[--top].~IM();
|
||||
}
|
||||
|
||||
|
||||
public: //-----RefArray-Interface------------
|
||||
|
||||
virtual size_t size() const
|
||||
{
|
||||
return n;
|
||||
}
|
||||
|
||||
virtual B const& operator[] (size_t i) const
|
||||
{
|
||||
REQUIRE (i < size());
|
||||
return array_[i];
|
||||
}
|
||||
|
||||
};
|
||||
|
||||
|
||||
} // namespace lib
|
||||
#endif
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
/*
|
||||
REF-ARRAY.hpp - abstraction providing array-like access to a list of references
|
||||
|
||||
Copyright (C)
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by the
|
||||
Free Software Foundation; either version 2 of the License, or (at your
|
||||
option) any later version. See the file COPYING for further details.
|
||||
|
||||
*/
|
||||
|
||||
|
||||
/** @file ref-array.hpp
|
||||
** Abstraction interface: array-like access by subscript
|
||||
** @todo as of 2016, this concept seems very questionable: do we _really_ want
|
||||
** to abstract over random access, or do we _actually_ want for-iteration??
|
||||
** @deprecated 5/2025 to be obsoleted by a similar design
|
||||
** @see several.hpp
|
||||
*/
|
||||
|
||||
|
||||
#ifndef LIB_REF_ARRAY_H
|
||||
#define LIB_REF_ARRAY_H
|
||||
|
||||
|
||||
#include "lib/nocopy.hpp"
|
||||
|
||||
|
||||
namespace lib {
|
||||
|
||||
/**
|
||||
* Abstraction: Array of const references.
|
||||
* Typically the return type is an interface,
|
||||
* and the Implementation wraps some datastructure
|
||||
* holding subclasses.
|
||||
* @todo ouch -- a collection that isn't iterable... ///////////////////////TICKET #1040
|
||||
* @warning in rework 5/2025
|
||||
*/
|
||||
template<class T>
|
||||
class RefArray
|
||||
: util::NonCopyable
|
||||
{
|
||||
public:
|
||||
virtual ~RefArray() {} ///< this is an interface
|
||||
|
||||
virtual T const& operator[] (size_t i) const =0;
|
||||
virtual size_t size() const =0;
|
||||
};
|
||||
|
||||
|
||||
} // namespace lib
|
||||
#endif
|
||||
|
|
@ -44,12 +44,12 @@
|
|||
#include "steam/mobject/placement.hpp"
|
||||
#include "steam/mobject/mobject-ref.hpp"
|
||||
#include "common/query/defs-manager.hpp" ////////////////////////////TICKET #643 forward declare this?
|
||||
#include "lib/ref-array.hpp"
|
||||
#include "lib/depend.hpp"
|
||||
#include "lib/symbol.hpp"
|
||||
#include "lib/p.hpp"
|
||||
|
||||
#include <memory>
|
||||
#include <vector>
|
||||
|
||||
|
||||
|
||||
|
|
@ -103,8 +103,8 @@ namespace mobject {
|
|||
protected:
|
||||
typedef lumiera::query::DefsManager& DefaultsAccess;
|
||||
typedef session::ElementQuery& ElementsAccess;
|
||||
typedef lib::RefArray<asset::PTimeline>& TimelineAccess;
|
||||
typedef lib::RefArray<asset::PSequence>& SequenceAccess;
|
||||
typedef std::vector<asset::PTimeline> const& TimelineAccess;
|
||||
typedef std::vector<asset::PSequence> const& SequenceAccess;
|
||||
|
||||
|
||||
Session (DefaultsAccess,
|
||||
|
|
|
|||
|
|
@ -552,11 +552,6 @@ return: 0
|
|||
END
|
||||
|
||||
|
||||
TEST "RefArray_test" RefArray_test <<END
|
||||
return: 0
|
||||
END
|
||||
|
||||
|
||||
TEST "verify removing values from a set" RemoveFromSet_test <<END
|
||||
out-lit: removed nothing ---> [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]
|
||||
out-lit: removed 0 ---> [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ]
|
||||
|
|
|
|||
|
|
@ -1,238 +0,0 @@
|
|||
/*
|
||||
RefArray(Test) - unittest for wrapping with array-of-refs access
|
||||
|
||||
Copyright (C)
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by the
|
||||
Free Software Foundation; either version 2 of the License, or (at your
|
||||
option) any later version. See the file COPYING for further details.
|
||||
|
||||
* *****************************************************************/
|
||||
|
||||
/** @file ref-array-test.cpp
|
||||
** unit test \ref RefArray_test
|
||||
** @deprecated 5/2024 rework underway
|
||||
** @see several-buider-test.cpp
|
||||
*/
|
||||
|
||||
|
||||
#include "lib/test/run.hpp"
|
||||
#include "lib/util.hpp"
|
||||
|
||||
#include "lib/ref-array-impl.hpp"
|
||||
|
||||
#include <vector>
|
||||
|
||||
using ::test::Test;
|
||||
using std::vector;
|
||||
|
||||
|
||||
namespace lib {
|
||||
namespace test{
|
||||
|
||||
namespace { // test types
|
||||
|
||||
struct I
|
||||
{
|
||||
virtual int op(int i) const =0;
|
||||
virtual ~I() {}
|
||||
};
|
||||
|
||||
struct Sub1 : I
|
||||
{
|
||||
int offs_;
|
||||
|
||||
Sub1 (int o=1) : offs_(o) {}
|
||||
|
||||
int op (int i) const { return i+offs_; }
|
||||
};
|
||||
|
||||
struct Sub2 : I
|
||||
{
|
||||
const char* letterz_;
|
||||
Sub2() : letterz_("ABCDEFGHIJKLMNOPQRSTUVWXYZ") {}
|
||||
|
||||
int op (int i) const { return (int)letterz_[i % 26]; }
|
||||
};
|
||||
|
||||
struct Sub3 : I
|
||||
{
|
||||
int id_;
|
||||
static long sum;
|
||||
static long trigger;
|
||||
|
||||
Sub3(int id) : id_(id)
|
||||
{
|
||||
sum +=id_;
|
||||
if ( id_ == trigger )
|
||||
throw trigger; // fail while in construction
|
||||
}
|
||||
~Sub3()
|
||||
{
|
||||
sum -=id_;
|
||||
}
|
||||
|
||||
int op (int i) const { return i + id_; }
|
||||
};
|
||||
|
||||
long Sub3::sum = 0;
|
||||
long Sub3::trigger = -1;
|
||||
|
||||
|
||||
} // (END) test types
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/***************************************************************//**
|
||||
* @test build several wrappers, each based on a different storage,
|
||||
* all providing RefArray access to a given vector. The rationale
|
||||
* for RefArray is to expose just the interface: the data structure
|
||||
* within the actual implementation holds subclass instances of
|
||||
* the specified interface.
|
||||
* - RefArrayVectorWrapper is a ref to an existing vector
|
||||
* - RefArrayVector subclasses std::vector
|
||||
* - RefArrayTable holds a fix sized table, i.e. embedded storage
|
||||
*
|
||||
* @see ref-array-impl.hpp
|
||||
*/
|
||||
class RefArray_test : public Test
|
||||
{
|
||||
|
||||
virtual void
|
||||
run (Arg)
|
||||
{
|
||||
seedRand();
|
||||
|
||||
checkWrapper();
|
||||
checkVector();
|
||||
checkTable();
|
||||
checkTable_inplaceCreation();
|
||||
checkTable_errorHandling();
|
||||
}
|
||||
|
||||
|
||||
|
||||
void
|
||||
checkWrapper()
|
||||
{
|
||||
vector<Sub2> subz(10);
|
||||
RefArrayVectorWrapper<I,Sub2> subWrap (subz);
|
||||
|
||||
RefArray<I> & rArr (subWrap);
|
||||
|
||||
CHECK (subWrap.size()==subz.size());
|
||||
CHECK (INSTANCEOF(I, &rArr[0]));
|
||||
for (size_t i=0; i<rArr.size(); ++i)
|
||||
{
|
||||
CHECK (&rArr[i] == &subz[i]);
|
||||
CHECK (rArr[i].op(i) == subz[i].op(i));
|
||||
}
|
||||
}
|
||||
|
||||
void
|
||||
checkVector()
|
||||
{
|
||||
RefArrayVector<I,Sub2> subz(10);
|
||||
|
||||
vector<Sub2> & vect (subz);
|
||||
RefArray<I> & rArr (subz);
|
||||
|
||||
CHECK (vect.size()==subz.size());
|
||||
CHECK (INSTANCEOF(I, &rArr[0]));
|
||||
for (size_t i=0; i<rArr.size(); ++i)
|
||||
{
|
||||
CHECK (&rArr[i] == &vect[i]);
|
||||
CHECK (rArr[i].op(i) == vect[i].op(i));
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
#define ADR(OBJ) (ulong)&(OBJ)
|
||||
|
||||
void
|
||||
checkTable()
|
||||
{
|
||||
RefArrayTable<I,20,Sub1> tab;
|
||||
// creates 20 Sub1-objects in-place
|
||||
// which are indeed located within the object
|
||||
CHECK (sizeof(tab) >= 20 * sizeof(Sub1));
|
||||
CHECK (ADR(tab) < ADR(tab[19]) && ADR(tab[19]) < ADR(tab) + sizeof(tab));
|
||||
|
||||
RefArray<I> & rArr (tab);
|
||||
|
||||
CHECK (20 == tab.size());
|
||||
CHECK (INSTANCEOF(I, &rArr[0]));
|
||||
for (size_t i=0; i<rArr.size(); ++i)
|
||||
{
|
||||
CHECK (i*sizeof(Sub1) == ADR(rArr[i]) - ADR(rArr[0]) ); // indeed array-like storage
|
||||
CHECK (int(i+1) == rArr[i].op(i)); // check the known result
|
||||
}
|
||||
}
|
||||
|
||||
template<class SUB>
|
||||
struct Fac ///< fabricating a series of subclass instances with varying ctor parameter
|
||||
{
|
||||
int offset_;
|
||||
Fac ( ) : offset_ (0) {}
|
||||
|
||||
void operator() (void* place)
|
||||
{
|
||||
CHECK (place);
|
||||
new(place) SUB (offset_++); // note: varying ctor parameter
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
void
|
||||
checkTable_inplaceCreation()
|
||||
{
|
||||
Fac<Sub1> theFact;
|
||||
RefArrayTable<I,30,Sub1> tab (theFact);
|
||||
RefArray<I> & rArr (tab);
|
||||
CHECK (30 == tab.size());
|
||||
for (size_t i=0; i<rArr.size(); ++i)
|
||||
CHECK (int(i+i) == rArr[i].op(i)); // each one has gotten another offset ctor parameter
|
||||
}
|
||||
|
||||
|
||||
void
|
||||
checkTable_errorHandling()
|
||||
{
|
||||
for (uint i=0; i<500; ++i)
|
||||
{
|
||||
Sub3::sum = 0;
|
||||
Sub3::trigger = rani(50); // when hitting the trigger Sub3 throws
|
||||
try
|
||||
{
|
||||
{
|
||||
Fac<Sub3> factory;
|
||||
RefArrayTable<I,30,Sub3> table (factory);
|
||||
CHECK (Sub3::sum == (29+1)*29/2);
|
||||
}
|
||||
CHECK (Sub3::sum == 0);
|
||||
}
|
||||
|
||||
catch(long id)
|
||||
{
|
||||
CHECK (id == Sub3::trigger);
|
||||
CHECK (Sub3::sum == id);
|
||||
// meaning: all objects have been cleaned up,
|
||||
// with the exception of the one hitting the trigger
|
||||
} }
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
|
||||
/** Register this test class... */
|
||||
LAUNCHER (RefArray_test, "unit common");
|
||||
|
||||
|
||||
|
||||
}} // namespace lib::test
|
||||
|
|
@ -75156,6 +75156,7 @@
|
|||
<linktarget COLOR="#2a45b9" DESTINATION="ID_1490841818" ENDARROW="Default" ENDINCLINATION="-1217;-20;" ID="Arrow_ID_1140294930" SOURCE="ID_1036649579" STARTARROW="None" STARTINCLINATION="-582;56;"/>
|
||||
<font NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1748736911007" ID="ID_1960135352" MODIFIED="1748736919447" TEXT="Form">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1533918279368" FOLDED="true" ID="ID_90099848" MODIFIED="1720131398331" TEXT="Assets">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1533918370708" ID="ID_1044798440" MODIFIED="1557498707237" TEXT="Arten">
|
||||
|
|
@ -75362,6 +75363,10 @@
|
|||
</node>
|
||||
<node CREATED="1533918281880" ID="ID_1584868520" MODIFIED="1557498707237" TEXT="MObject"/>
|
||||
</node>
|
||||
<node CREATED="1748736913830" ID="ID_747669722" MODIFIED="1748737076982" TEXT="Repräsentation">
|
||||
<arrowlink COLOR="#802752" DESTINATION="ID_1289244616" ENDARROW="Default" ENDINCLINATION="-1333;61;" ID="Arrow_ID_657332017" STARTARROW="None" STARTINCLINATION="-1024;178;"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1674160453319" ID="ID_1069058254" MODIFIED="1674160457633" TEXT="Fragen der Anordnung">
|
||||
<node CREATED="1674160465628" ID="ID_1715063705" MODIFIED="1674160468831" TEXT="Konventionen"/>
|
||||
<node CREATED="1674160469453" ID="ID_299990959" MODIFIED="1674160474856" TEXT="möglicher Spielraum">
|
||||
|
|
@ -159241,6 +159246,234 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
|
|||
<node CREATED="1737320216607" ID="ID_900361053" MODIFIED="1737320223218" TEXT="algebraische Terme"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1748737119043" ID="ID_1848488024" MODIFIED="1748737134366">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Lumiera verarbeitet vor allem <b>Metadaten</b>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1748737156496" ID="ID_1872021141" MODIFIED="1748737233491">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<u>High-Level</u>: die Session ist ein Syntax-Baum mit Attribution
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1748819280378" ID="ID_1774937798" MODIFIED="1748819323823" TEXT="Aufgabe der Auslegung">
|
||||
<node CREATED="1748819358981" ID="ID_1273029818" MODIFIED="1748819569171">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p style="text-align: center">
|
||||
Auf konzeptioneller Ebene
|
||||
</p>
|
||||
<p style="text-align: center">
|
||||
und für das UI : klar gegeben
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1748819387961" ID="ID_1349302951" MODIFIED="1748819405976" TEXT="wir haben Dinge in IT-technischer Repräsentation"/>
|
||||
<node CREATED="1748819406899" ID="ID_650235939" MODIFIED="1748819421494" TEXT="diese werden platziert, arrangiert und verbunden"/>
|
||||
<node CREATED="1748819422245" ID="ID_240737761" MODIFIED="1748819434597" TEXT="wir bestimmen ihre Eigenschaften"/>
|
||||
<node CREATED="1748819437673" ID="ID_812276048" MODIFIED="1748819453181" TEXT="und das daraus zusammengefügte Gebilde wird der Film"/>
|
||||
</node>
|
||||
<node CREATED="1748819528398" ID="ID_1081660572" MODIFIED="1748819553464" TEXT="für ein Script">
|
||||
<node CREATED="1748819593395" ID="ID_208217039" MODIFIED="1748819597122" TEXT="zwei Sichten">
|
||||
<node CREATED="1748819603106" ID="ID_1565720479" MODIFIED="1748819683894" TEXT="automatisierte Steuerung der im UI zugänglichen Verhältnisse"/>
|
||||
<node CREATED="1748819684784" ID="ID_1868118899" MODIFIED="1748819729931" TEXT="automatisiertes Operieren mit den Bestandteilen der Session"/>
|
||||
</node>
|
||||
<node CREATED="1748819807960" ID="ID_1579506210" MODIFIED="1748819826131" TEXT="man möchte die Objekte direkt als Objekte der Skriptsprache"/>
|
||||
<node CREATED="1748819848677" ID="ID_1129284982" MODIFIED="1748819867507" TEXT="man möchte Operationen unmittelbar ausführen, ohne weitere »Zeremonie«"/>
|
||||
</node>
|
||||
<node CREATED="1748819914478" ID="ID_1617010948" MODIFIED="1748819924060" TEXT="für die Implementierung von Session-Commands">
|
||||
<node CREATED="1748819939337" ID="ID_1433995333" MODIFIED="1748819987841">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p style="text-align: right">
|
||||
das Command steht für einen Satz,
|
||||
</p>
|
||||
<p style="text-align: right">
|
||||
der einen Auftrag erteilt
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748820031323" ID="ID_829413319" MODIFIED="1748820080683" TEXT="explizit gegeben ist das Subjekt der Instruktion"/>
|
||||
<node CREATED="1748820081530" ID="ID_460818217" MODIFIED="1748820252929" TEXT="von dort muß aller notwendige Kontext zugänglich sein">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
diese Forderung kann in doppelter Hinsicht verstanden werden...
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
wenn ich schon eine Instruktion habe, muß ich vom Subjekt alle weiteren Beteiligten erreichen können; im Besonderen einen Kontext, in dem sich das Subjekt befindet, und welcher eigentlich <i>eine koordinierte Aktion vollziehen muß,</i> um die Instruktion zu verwirklichen
|
||||
</li>
|
||||
<li>
|
||||
das Command und damit die Instruktion ist so anzuordnen, daß das Subjekt der Instruktion die notwendige Souveränität hat, um die Instruktion vollumfänglich zu verwirklichen
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748820488482" ID="ID_601612448" MODIFIED="1748820507518" TEXT="es handelt sich i.d.R um eine einfache Binding/ oder Mapping-Aufgabe"/>
|
||||
<node CREATED="1748820508425" ID="ID_275704911" MODIFIED="1748820522004" TEXT="Verwendung eines technischen Meta-Interfaces ist denkbar"/>
|
||||
<node CREATED="1748820555540" ID="ID_311044165" MODIFIED="1748820615010" TEXT="Framework-Code und »Zeremonie« ist zu vermeiden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
....denn andernfalls werden mit hoher Wahrscheinlichkeit fehlerhaft bzw. unvollständig definierte Commands auftreten
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1748737022343" ID="ID_1289244616" MODIFIED="1748737645948">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
auf welcher Art Repräsentation
|
||||
</p>
|
||||
<p>
|
||||
wird in der Session gearbeitet?
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#802752" DESTINATION="ID_1289244616" ENDARROW="Default" ENDINCLINATION="-1333;61;" ID="Arrow_ID_657332017" SOURCE="ID_747669722" STARTARROW="None" STARTINCLINATION="-1024;178;"/>
|
||||
<linktarget COLOR="#ff0014" DESTINATION="ID_1289244616" ENDARROW="Default" ENDINCLINATION="33;398;" ID="Arrow_ID_974738759" SOURCE="ID_1539358489" STARTARROW="None" STARTINCLINATION="537;-744;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1748737260968" ID="ID_407734575" MODIFIED="1748819321306" TEXT="anders gefragt: gibt es überhaupt »Business-Logik«">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<ul>
|
||||
<li>
|
||||
Wobei unter <i>Business-Logik</i> verstanden wird, daß gewisse Verarbeitungs-Schemata, die sich an der Target-Domain orientieren, direkt in Code zur Datenverarbeitung übersetzt worden sind. Man kann dann „im Code sehen was das System macht“.
|
||||
</li>
|
||||
<li>
|
||||
Das andere Extrem wäre, wenn ein System lediglich eine Meta-Verarbeitung implementiert, wähend Logik und Inhalt der Verarbeitung in Parametern und Arbeitsdaten steckt.
|
||||
</li>
|
||||
<li>
|
||||
Ein Zwischending wäre die »Pinball-Machine«: bei dieser steckt die Verarbeitungs-Struktur in der Verschaltung, über welche Ereignisse weitergeleitet und beantwortet werden
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1748820700549" ID="ID_1277609627" MODIFIED="1748820858649" TEXT="wenig bis gar nicht">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
überwiegend geht es darum, verbundene oder betroffene weitere Objekte zu finden, oder einen Kontext zu erlangen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748820705893" ID="ID_318155844" MODIFIED="1748820824091" TEXT="und wenn, bleibt sie auf Command-Ebene unsichtbar">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn das Command <i>bestimmt was getan werden soll</i> — ob das dann tatsächlich passiert, oder gar weitere Konsequenzen hat, stellt sich in der Verarbeitung heraus und wird als Ergebnis-Feedback asynchron zurückgemeldet
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1748820880468" ID="ID_450822655" MODIFIED="1748820907525" TEXT="»Metadaten« kann mehrere Bedeutungen haben">
|
||||
<node CREATED="1748820919900" ID="ID_1256467001" MODIFIED="1748820949470" TEXT="Daten aus einer Spezifikations-Datenbank"/>
|
||||
<node CREATED="1748820961743" ID="ID_497098876" MODIFIED="1748820969754" TEXT="Algebraische Terme und Prädikate"/>
|
||||
<node CREATED="1748820989134" ID="ID_26494541" MODIFIED="1748821007829" TEXT="Objekte einer Domänen-Modellierung"/>
|
||||
</node>
|
||||
<node CREATED="1748821076318" ID="ID_1490582004" MODIFIED="1748821080801" TEXT="Einschätzung">
|
||||
<node CREATED="1748821082527" ID="ID_138839350" MODIFIED="1748821192809" TEXT="Datenbank-Daten und algebraische Terme wären die natürliche Repräsentation">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
und zwar „natürlich“ aus Sicht dessen, was hier geschieht, also aus Sicht der Implementierung. Dem würde eine technische / Meta-Schnittstelle entsprechen, auf der man eine Art »instruction code« absetzt
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748821196209" ID="ID_1040225824" MODIFIED="1748821353396" TEXT="was es sicher nicht bedeutet: daß man die eigentliche Medien-Implementierung manipuliert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Es wird also definitiv nicht »der Clip« den Code enthalten, wie <i>er sich selber rendert,</i> oder »der Track« den Code enhalten, mit dem Mediendaten kombiniert und verarbeitet werden.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748821580331" ID="ID_586599540" MODIFIED="1748821639455" TEXT="Möglichkeit zur Anreicherung mit weiteren Metadaten wird benötigt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
und zwar muß das einzelne Objekt im Stande sein, beliebige, lokal opaque aber stukturierte Daten zu transportieren
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748821683132" ID="ID_1469699624" MODIFIED="1748821699766" TEXT="die Domänen-Modellierung ist am nächsten an den Erwartungen und Anforderungen"/>
|
||||
</node>
|
||||
<node CREATED="1748821716345" ID="ID_1339581237" MODIFIED="1748821720597" TEXT="Achitektur-Skizze">
|
||||
<node CREATED="1748821721658" ID="ID_666952299" MODIFIED="1748821726347" TEXT="wir bleiben bei Objekten">
|
||||
<node CREATED="1748821727418" ID="ID_1175981783" MODIFIED="1748821747342" TEXT="sie haben direkte Wert-Attribute"/>
|
||||
<node CREATED="1748821748450" ID="ID_1398961450" MODIFIED="1748821757127" TEXT="sie bieten Methoden zur Manipulation"/>
|
||||
<node CREATED="1748821758924" ID="ID_1481443258" MODIFIED="1748821773925" TEXT="Objekte haben eine interne Service-Verdrahtung"/>
|
||||
<node CREATED="1748821774728" ID="ID_1424108521" MODIFIED="1748821783705" TEXT="die Methoden leisten die Übersetzung in Events"/>
|
||||
<node CREATED="1748821789065" ID="ID_201559458" MODIFIED="1748821809701" TEXT="Objekte werden als Polymorphic-Value repräsentiert"/>
|
||||
<node CREATED="1748821820591" ID="ID_7700102" MODIFIED="1748821831500" TEXT="Objekt-Argumente werden stets per Referenz genommen"/>
|
||||
</node>
|
||||
<node CREATED="1748821839481" ID="ID_136996698" MODIFIED="1748821855026" TEXT="Identität wird als Identifier materialisiert"/>
|
||||
<node CREATED="1748821855926" ID="ID_1891952955" MODIFIED="1748822531261" TEXT="das heißt: wir arbeiten weitgehend mit Wert-Semantik">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Und nicht mit Referenz-Semantik, wie ursprünglich beabsichtigt. All die smart-Pointer mit angebundenem Memory-Management fallen weg; stattdessen arbeiten wir pervasiv mit EntryIDs. Placements liegen nur noch im Placement-Index, werden aber extern ausschließlich als ID-basierte Referenzen gehandhabt
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748822095685" ID="ID_1018969075" MODIFIED="1748822429641" TEXT="jeder Verarbeitungsschritt bekommt Objekt-Kopien">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Objekte sind stets vergleichsweise klein. Wo das schwierig wird, arbeiten wir mit Proxies (z.B. lib::Literal oder lib::Symbol für Strings). Zu einer gegebenen EntryID kann man stets eine Objekt-Kopie bekommen; auch ein Command bezieht solche Kopien, um darauf eine Methode aufzurufen, welche intern, über Session-Services die entsprechenden Events auslösen. Auch der nachfolgende Builder-Lauf zieht sich eine Kopie des Session-Inhalts
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1748822110420" ID="ID_636425002" MODIFIED="1748822124312" TEXT="die Session enthält einen verbindlichen Modell-Bestand"/>
|
||||
<node CREATED="1748822125067" ID="ID_1713086918" MODIFIED="1748822141962" TEXT="dieser Modell-Bestand ist eine »Projektion« im Sinn von CQRS"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1748737180852" ID="ID_1653171650" MODIFIED="1748737227045">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<u>Low-Level</u>: die Nodes sind ein funktionaler Aufruf-Plan
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1737319070929" ID="ID_1581929006" MODIFIED="1737319192871">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
|
|
@ -163455,13 +163688,14 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1744756270441" ID="ID_831819953" LINK="https://issues.lumiera.org/ticket/473" MODIFIED="1746059845274" TEXT="RefArray und ScopedHolder müssen jetzt wirklich mal weg">
|
||||
<node COLOR="#338800" CREATED="1744756270441" ID="ID_831819953" LINK="https://issues.lumiera.org/ticket/473" MODIFIED="1748738386934" TEXT="RefArray und ScopedHolder müssen jetzt wirklich mal weg">
|
||||
<arrowlink COLOR="#fd26d0" DESTINATION="ID_1135941103" ENDARROW="Default" ENDINCLINATION="-1048;89;" ID="Arrow_ID_1050531240" STARTARROW="None" STARTINCLINATION="-1120;-23;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1747180091430" ID="ID_202566672" MODIFIED="1747180099934" TEXT="was ist mit ScopedPtrvect?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
<node CREATED="1748609941535" ID="ID_309992355" MODIFIED="1748609956540" TEXT="Status feststellen">
|
||||
<node COLOR="#435e98" CREATED="1748609941535" ID="ID_309992355" MODIFIED="1748738408223" TEXT="Status feststellen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node COLOR="#338800" CREATED="1748609976008" FOLDED="true" ID="ID_406349837" LINK="https://issues.lumiera.org/ticket/1059" MODIFIED="1748647349774" TEXT="#1059 verify and use perfect forwarding">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1748610060693" ID="ID_1805620153" MODIFIED="1748646943713" TEXT="damit noch markierte Stellen betrachten">
|
||||
|
|
@ -163804,7 +164038,7 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#c8b6c1" COLOR="#435e98" CREATED="1748712767350" ID="ID_1069989891" MODIFIED="1748712793537" TEXT="tot ��"/>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1748730829818" ID="ID_700236683" MODIFIED="1748730848701" TEXT="nicht verwendet ... schnell weg damit">
|
||||
<node COLOR="#5b280f" CREATED="1748730829818" FOLDED="true" ID="ID_700236683" MODIFIED="1748732380623" TEXT="nicht verwendet ... schnell weg damit">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1748730811995" ID="ID_1675553345" MODIFIED="1748730820630" TEXT="nobug-resource-handle-context"/>
|
||||
<node CREATED="1748730821812" ID="ID_1395653066" MODIFIED="1748730826587" TEXT="simple-allocator"/>
|
||||
|
|
@ -163813,9 +164047,7 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<node CREATED="1748731125255" ID="ID_1963832206" MODIFIED="1748731133648" TEXT="wir brauchen strukturierte, algebraische IDs"/>
|
||||
<node CREATED="1748731134567" ID="ID_1264506394" MODIFIED="1748731197197" TEXT="aber wenn schon, dann auch tatsächlich ernsthaft implementiert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
ein Müll-Header mit einem Dummy-Test, der seit > 10 Jahren herumliegt, und alle wichtigen Probleme nicht löst ...
|
||||
|
|
@ -163824,8 +164056,7 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<i>dann kann man auch gleich von Null anfangen</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1748731241722" ID="ID_1013782064" MODIFIED="1748731245961" TEXT="vcall.h">
|
||||
|
|
@ -163834,6 +164065,126 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1748731316160" ID="ID_1388202310" MODIFIED="1748731324655" TEXT="hash-fnv.h|c"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#bc9daa" COLOR="#5b280f" CREATED="1748732382635" ID="ID_365290009" MODIFIED="1748737931585" STYLE="fork" TEXT="RefArray ��">
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1748732389628" ID="ID_344324779" MODIFIED="1748737931582" TEXT="eine Verwendung auf dem Session-Interface">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1748732426725" ID="ID_280482100" MODIFIED="1748737931582" TEXT="also wirklich: Interface-hat-eine-Collection"/>
|
||||
<node CREATED="1748732511785" ID="ID_1712841924" MODIFIED="1748737931582" TEXT="und zwar mit shared-Pointern"/>
|
||||
<node BACKGROUND_COLOR="#c3aba4" COLOR="#990033" CREATED="1748732564173" ID="ID_329324495" MODIFIED="1748737931582" TEXT="was für eine Abstraktion wird denn hier gebraucht?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node COLOR="#5b280f" CREATED="1748732586054" ID="ID_984326516" MODIFIED="1748737931582" TEXT="ist da irgendwo ein (opaque) Sub-Typ involviert?">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node CREATED="1748732726586" ID="ID_595830892" MODIFIED="1748737931582" TEXT="nein; sondern der Container selber ist eine Abstraktion"/>
|
||||
<node CREATED="1748732739437" ID="ID_1194985494" MODIFIED="1748737931582" TEXT="implementiert wird als ElementTracker —▷ RefArrayVector">
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node CREATED="1748733405294" ID="ID_913940989" MODIFIED="1748737931582" TEXT="die verschiedenen Objekt-Arten werden generisch behandelt — nicht polymorph">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#e200bd" CREATED="1748733433864" ID="ID_1028771402" MODIFIED="1748737931582" TEXT="Schwein gehabt">
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1748733519315" ID="ID_843259489" MODIFIED="1748737931582" TEXT="Verwendung der Timeline/Sequence-Accessoren">
|
||||
<icon BUILTIN="edit"/>
|
||||
<node CREATED="1748733527340" ID="ID_1987018959" MODIFIED="1748737931582" TEXT="gibt es eine Menge"/>
|
||||
<node CREATED="1748733531151" ID="ID_104771213" MODIFIED="1748737931582" TEXT="aber ich weiß daß das alles Platzhalter-Code ist"/>
|
||||
<node BACKGROUND_COLOR="#dac1b2" COLOR="#a50125" CREATED="1748733552077" ID="ID_1539358489" MODIFIED="1748737931582" TEXT="es ist immer noch überhaupt nicht klar welches Session-Interface gebraucht wird">
|
||||
<arrowlink COLOR="#ff0014" DESTINATION="ID_1289244616" ENDARROW="Default" ENDINCLINATION="33;398;" ID="Arrow_ID_974738759" STARTARROW="None" STARTINCLINATION="537;-744;"/>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
<node CREATED="1748733572026" ID="ID_1804348424" MODIFIED="1748737931582" TEXT="Stichwort: generisch vs. spezifisch"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1748733713805" ID="ID_1716101761" MODIFIED="1748737931582" TEXT="wegen Event-Sourcing kann die Session keine »Implementierungs-Objekte« enthalten">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1748733791073" ID="ID_1437256753" MODIFIED="1748737931582" TEXT="wobei der Gehalt dieser „Implementierung“ ohnehin nie so recht klar war"/>
|
||||
<node CREATED="1748733830376" ID="ID_728052298" MODIFIED="1748737931582" TEXT="also könnte...">
|
||||
<node CREATED="1748733835406" ID="ID_155518420" MODIFIED="1748737931582" TEXT="die Session ein Property-Tree sein"/>
|
||||
<node CREATED="1748733845924" ID="ID_1715760843" MODIFIED="1748737931582" TEXT="oder sie könnte symbolische Platzhalter enthalten"/>
|
||||
</node>
|
||||
<node CREATED="1748734349031" ID="ID_1886447558" MODIFIED="1748737931582" TEXT="es könnte auch sein....">
|
||||
<node CREATED="1748734354497" ID="ID_476637960" MODIFIED="1748737931582" TEXT="daß auf die Sesseion gar nicht mehr daten-zentrisch zugegriffen wird"/>
|
||||
<node CREATED="1748734370822" ID="ID_1791599272" MODIFIED="1748737931582" TEXT="sondern nur noch per Callback über eine Objekt-ID"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ddb79b" COLOR="#5b280f" CREATED="1748734402026" ID="ID_761844471" MODIFIED="1748737931582" TEXT="Aber: wie sollte man das jemals herausfinden können">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
<node CREATED="1748734632851" ID="ID_1162134510" MODIFIED="1748737931582" TEXT="will sagen: erst mal muß man es schon implementieren"/>
|
||||
<node CREATED="1748734648174" ID="ID_1158758052" MODIFIED="1748737931582" TEXT="um es dann diskutieren und letztlich anders machen zu können"/>
|
||||
</node>
|
||||
<node CREATED="1748734790313" ID="ID_1549532218" MODIFIED="1748737931582">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
der nächste »Vertical Slice« <b>wird das entscheiden müssen</b>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn im nächsten Slice wird <i>das Agens festgelegt, auf dem der Builder arbeitet....</i>
|
||||
</p>
|
||||
<p>
|
||||
Daran wird sich dann anmessen, was für eine Repräsentation in der Session liegt 
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1748735071405" ID="ID_611636546" MODIFIED="1748737931583" TEXT="Fazit">
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="back"/>
|
||||
<node CREATED="1748735076771" ID="ID_1932129798" MODIFIED="1748737931583" TEXT="wir erhalten erst einmal den Status-quo"/>
|
||||
<node CREATED="1748735089726" ID="ID_930844028" MODIFIED="1748737931583" TEXT="und betrachten diese Objekte aber als symbolische Platzhalter"/>
|
||||
<node CREATED="1748733473387" ID="ID_1536258078" MODIFIED="1748737931583">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
man könnte also RefArray durch eine <font face="Monospaced" color="#331dc8"><b>const vector&</b></font>  ersetzen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#b0d8cd" COLOR="#338800" CREATED="1748736160142" ID="ID_270025509" MODIFIED="1748737931583" TEXT="das geht verblüffend einfach">
|
||||
<linktarget COLOR="#27c271" DESTINATION="ID_270025509" ENDARROW="Default" ENDINCLINATION="-700;44;" ID="Arrow_ID_1173221972" SOURCE="ID_1525129133" STARTARROW="None" STARTINCLINATION="193;15;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1748736172483" ID="ID_1273083458" MODIFIED="1748737931583" TEXT="was zeigt: der bestehende Platzhalter-Code ist oberflächlich">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1748737775178" ID="ID_1525129133" MODIFIED="1748737931583" TEXT="diese läßt sich banal einfach ersetzen">
|
||||
<arrowlink COLOR="#27c271" DESTINATION="ID_270025509" ENDARROW="Default" ENDINCLINATION="-700;44;" ID="Arrow_ID_1173221972" STARTARROW="None" STARTINCLINATION="193;15;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#21755f" CREATED="1748737841954" HGAP="23" ID="ID_498489405" MODIFIED="1748737931583" VSHIFT="-40">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p style="text-align: right">
|
||||
weil zum Glück
|
||||
</p>
|
||||
<p style="text-align: right">
|
||||
die Abstraktions-Eigenschaft
|
||||
</p>
|
||||
<p style="text-align: right">
|
||||
gar nicht verwendet wurde
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue